CVE-2026-46495 in OpenDJ
Summary
by MITRE • 09/15/2026
OpenDJ is an LDAPv3 compliant directory service. Prior to 5.1.1, the JMX RMI connector in opendj-server-legacy/src/main/java/org/opends/server/protocols/jmx/RmiConnector.java processes attacker-controlled credential objects before authentication without a restrictive jmx.remote.rmi.server.credentials.filter.pattern, and RmiAuthenticator.authenticate in opendj-server-legacy/src/main/java/org/opends/server/protocols/jmx/RmiAuthenticator.java accepts an unconstrained Object array rather than a two-element String[]. When the JMX Connection Handler is enabled and its TCP listener is reachable, an unauthenticated remote attacker can submit a crafted serialized Java object and achieve code execution in the OpenDJ server process. The handler is disabled by default, and successful exploitation depends on the runtime classpath and Java version; remote code execution was demonstrated against OpenDJ 4.4.15 on JDK 11 with Jackson 2.12.6.1. This issue is fixed in 5.1.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
OpenDJ, an LDAPv3 compliant directory service utilized for managing identity and access control data, contains a critical remote code execution vulnerability within its Java Management Extensions (JMX) Remote Method Invocation connector component. The flaw resides specifically in the handling of credential objects during the authentication phase prior to strict validation checks being applied. In versions preceding 5.1.1, the RmiConnector class processes attacker-controlled credential objects without enforcing a restrictive jmx.remote.rmi.server.credentials.filter.pattern. This absence allows maliciously crafted serialized Java objects to bypass initial security controls and enter the deserialization pipeline of the server process. The vulnerability is compounded by the implementation in the RmiAuthenticator class, which accepts an unconstrained Object array rather than strictly typed two-element String arrays for authentication credentials. This lack of type enforcement permits attackers to inject arbitrary object types that can be exploited during subsequent processing stages.
The operational impact of this vulnerability is severe, as it enables unauthenticated remote code execution on the target system provided specific conditions are met. The JMX Connection Handler must be explicitly enabled and its TCP listener must be reachable by the attacker over the network. When these prerequisites align, an adversary can submit a specially crafted serialized Java object that triggers unsafe deserialization within the OpenDJ server process. Successful exploitation relies heavily on the runtime classpath availability of specific libraries capable of facilitating gadget chain execution, as well as the version of the Java Development Kit in use. Demonstrated proof-of-concept attacks have successfully achieved code execution against OpenDJ 4.4.15 running on JDK 11 with Jackson library version 2.12.6.1 installed, illustrating that common serialization libraries present in many enterprise environments can be leveraged to execute arbitrary commands with the privileges of the OpenDJ service account.
From a classification perspective, this vulnerability aligns with CWE-502, which denotes Deserialization of Untrusted Data, as well as CWE-78, Improper Neutralization of Special Elements used in an OS Command if command execution is achieved via system calls. In terms of attack vectors and tactics, the exploitation method corresponds to ATT&CK technique T1059, specifically sub-techniques related to command and script interpreters or operating system API abuse depending on how the gadget chain executes code. The vulnerability also reflects CWE-284 Improper Access Control due to insufficient authentication checks before processing sensitive inputs. Organizations running OpenDJ must recognize that while the JMX handler is disabled by default, any configuration change enabling it exposes the infrastructure to this high-severity risk if not properly secured with credential filters and network access controls.
To mitigate this vulnerability, administrators should immediately upgrade to version 5.1.1 or later where the issue has been resolved through stricter input validation and enforcement of serialization filters. If upgrading is not immediately feasible, it is critical to ensure that the JMX Connection Handler remains disabled unless absolutely necessary for management operations. When enabled, strict network segmentation must be implemented to restrict access to the JMX TCP listener port exclusively from trusted administrative workstations or internal monitoring systems using firewall rules. Additionally, implementing a restrictive jmx.remote.rmi.server.credentials.filter.pattern can help block known malicious serialization patterns, although this is not a complete substitute for upgrading. Security teams should also audit their Java runtime environments to identify and remove unnecessary libraries that could serve as gadgets in deserialization attack chains, thereby reducing the potential impact even if an attacker manages to trigger the initial flaw.