OpenDJ DSMLv2 Gateway Vulnerability Allows Unauthenticated SSRF, Local File Read, and DoS
A remote, unauthenticated attacker can exploit a critical vulnerability in the DSMLv2 SOAP gateway (opendj-dsml-servlet) of OpenIdentityPlatform OpenDJ versions up to 5.1.1, allowing server-side request forgery (SSRF), local file reading via `file:` URIs, and denial-of-service (DoS) due to unbounded response reads by submitting specially crafted DSML add/modify requests.
A critical vulnerability exists in the DSMLv2 SOAP gateway, specifically the opendj-dsml-servlet component, within OpenIdentityPlatform OpenDJ versions through 5.1.1. This flaw allows a remote, unauthenticated attacker to perform server-side request forgery (SSRF) against internal services and cloud metadata endpoints, read arbitrary local files using file: URIs, and trigger a denial-of-service (DoS) condition. The vulnerability stems from the server's improper handling of attacker-supplied xsd:anyURI values, which are dereferenced without sufficient scheme allowlisting, egress filtering, or size limitations. The opendj-dsml-servlet is exposed without authentication by default, making exploitation straightforward. This vulnerability poses a significant risk of data exfiltration, internal network reconnaissance, and service disruption for affected organizations running vulnerable OpenDJ instances. The issue was addressed in OpenDJ version 5.1.2, which disables anyURI dereferencing by default and enforces strict validation and authentication when enabled.
Attack Chain
- An unauthenticated attacker identifies an internet-accessible OpenDJ instance running version 5.1.1 or older with the
opendj-dsml-servletcomponent exposed. - The attacker crafts a malicious DSML add/modify request containing a specially designed
xsd:anyURIvalue embedded within the request body. - To achieve local file access, the attacker specifies a
file:///URI, such asfile:///etc/passwd. For SSRF, an internal network URI likehttp://169.254.169.254/latest/meta-data/or an internal IP address is used. For a DoS attack, a URI pointing to a large, unbounded resource is chosen. - The crafted DSML request is then sent via an HTTP POST request to the vulnerable
opendj-dsml-servletendpoint. - The OpenDJ DSMLv2 gateway, lacking proper validation and egress filtering, attempts to dereference the attacker-supplied
xsd:anyURIvalue on the server side. - Upon successful exploitation:
- SSRF: The server makes a request to the specified internal service or cloud metadata endpoint, potentially exposing sensitive information or enabling interaction with internal network resources.
- Local File Read: The server reads the content of the local file specified by the
file:URI and includes it within its response, exfiltrating the data to the attacker. - DoS: The server attempts to read an unbounded response from the dereferenced URI, consuming excessive memory and leading to a denial-of-service condition for the OpenDJ instance.
Impact
Successful exploitation of this vulnerability by a remote, unauthenticated attacker can lead to significant consequences for affected organizations. Attackers can read sensitive local files, such as configuration files, password hashes, or other proprietary data, potentially leading to further compromise or data exfiltration. The ability to perform Server-Side Request Forgery (SSRF) allows attackers to interact with internal services that are otherwise not directly exposed to the internet, including cloud metadata endpoints, facilitating network reconnaissance, privilege escalation, or access to sensitive cloud resources. Furthermore, the unbounded response read vulnerability can cause memory exhaustion, leading to a denial-of-service condition that disrupts the availability of the OpenDJ service and potentially other dependent applications.
Recommendation
- Upgrade OpenDJ to version 5.1.2 or newer immediately to apply the security patches.
- Configure the
opendj-dsml-servletto require container-managed authentication by default, as introduced in version 5.1.2. - If immediate upgrade is not feasible, ensure that
anyURIdereferencing is disabled. IfanyURIdereferencing must be enabled, configure it to strictly limit to http/https allowlist, reject loopback, link-local, private, and reserved targets, refuse HTTP redirects, and cap the bytes read.