CVE-2026-84175: SSRF
In Eclipse Ditto versions 3.0.0 to 3.9.6, the Things service fetches WoT (Web of Things) ThingModels over HTTP from URLs supplied by API users in the definition field of a Thing or Feature, without validating the target host, and follows HTTP redirects without re-validating the redirect target and without a hop limit. An authenticated user who is permitted to create a Thing, or who holds WRITE permission on an existing Thing, can thereby cause the Things service to issue arbitrary HTTP GET requests from inside the deployment's network — including to cloud instance-metadata endpoints and other internal services — and can use the differing error responses returned to the caller to enumerate internal services. Versions 2.4.0 to 2.5.x contain the same code, but are only affected where the operator explicitly enabled the WoT integration feature toggle, which is disabled by default in those versions.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
For Ditto versions 2.4.0 to 2.5.x (where the WoT Things service code is present), ensure the WoT integration feature toggle is disabled (it is disabled by default), so the Things service does not fetch WoT ThingModels over HTTP from user-supplied URLs.
Eclipse Ditto WoT integration feature toggle WoT integration = disabled - Compensating control
Restrict outbound network access from the Ditto deployment so the Things service cannot reach cloud instance-metadata endpoints or other internal services (e.g., via firewall/egress controls), reducing impact from arbitrary internal HTTP GET requests.
Event History
Frequently Asked Questions
Which deployments are affected by default?
Eclipse Ditto 3.0.0 through 3.9.6 are affected. Versions 2.4.0 through 2.5.x are affected only if the operator explicitly enabled the WoT integration feature toggle, which is disabled by default in those versions.
What access does an attacker need to exploit this issue?
The attacker must be authenticated and able to create a Thing, or have WRITE permission on an existing Thing. They can then supply a URL in a Thing or Feature definition field.
What can an attacker reach through the vulnerable request behavior?
The Things service can be induced to make HTTP GET requests to arbitrary targets reachable from the deployment network, including cloud instance-metadata endpoints and internal services. Redirects are followed without validating each redirect target or enforcing a redirect hop limit.
How could this be used to identify internal services?
The caller can use differences in errors returned by the Things service to enumerate internal services. This means exposure is not limited to targets whose response content is directly returned.