CVE-2026-84218: Jolokia JSR-160 Proxy SSRF Vulnerability

CVE-2026-84218 Overview

CVE-2026-84218 is a denylist bypass vulnerability in Jolokia's JSR-160 proxy functionality. The proxy accepts a client-controlled target.url value from Jolokia POST requests and passes it directly to JMXServiceURL and JMXConnectorFactory. The existing denylist introduced to mitigate CVE-2018-1000130 only rejects URLs matching the pattern service:jmx:rmi:///jndi/ldap:.*. Attackers can bypass this filter using alternative JMX service URL forms, including ldaps:// schemes or LDAP URLs containing a non-empty JMX host component. Successful exploitation triggers a JNDI lookup against an attacker-controlled LDAP endpoint, enabling server-side request forgery (SSRF), JMX credential forwarding, and potential remote code execution.

Critical Impact
Attackers with network access to a Jolokia agent can coerce the JVM into performing JNDI lookups against attacker-controlled LDAP servers, potentially leading to remote code execution.

Affected Products

Jolokia Agent versions prior to 2.6.2
Applications embedding vulnerable Jolokia JSR-160 proxy functionality
Red Hat products bundling affected Jolokia components (see Red Hat CVE-2026-84218 Advisory)

Discovery Timeline

2026-09-01 - CVE-2026-84218 published to NVD
2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-84218

Vulnerability Analysis

Jolokia exposes Java Management Extensions (JMX) over HTTP and includes a JSR-160 proxy feature that forwards JMX operations to remote endpoints. The proxy reads the target.url field from a POST request body and constructs a JMXServiceURL before calling JMXConnectorFactory.connect(). To mitigate the earlier JNDI injection issue CVE-2018-1000130, maintainers added a denylist that rejects URLs matching service:jmx:rmi:///jndi/ldap:.*.

The filter is too narrow. It rejects only the literal ldap: scheme with an empty host component. Attackers can supply alternative forms that the JVM still resolves as valid JMX service URLs, such as URLs using the ldaps:// scheme or LDAP URLs with a non-empty host segment. These variants pass the check and reach JMXConnectorFactory, which triggers a JNDI lookup against the attacker-supplied endpoint.

This flaw is classified as [CWE-184: Incomplete List of Disallowed Inputs] and is a canonical example of denylist-based sanitization failing when the underlying parser accepts more input forms than the filter anticipates.

Root Cause

The root cause is insufficient validation of a client-controlled URL parameter. The denylist regex is anchored to a single scheme and empty-host form, while JMXServiceURL and the underlying JNDI subsystem accept many equivalent representations. Any input surface that hands untrusted URLs to JMXConnectorFactory inherits the JNDI attack surface unless validated using an allowlist of expected hosts and schemes.

Attack Vector

Exploitation requires network reachability to a Jolokia endpoint that exposes the JSR-160 proxy. An attacker submits a Jolokia POST request containing a crafted target.url value pointing at an LDAP or LDAPS server they control. The Jolokia agent JVM performs the JNDI lookup, which can return a serialized reference that the JVM resolves into a Java object. Depending on the classes present on the classpath and the JVM configuration, this can lead to arbitrary code execution, credential theft when JMX authentication material is forwarded, or SSRF against internal services.

See the GitHub Security Advisory GHSA-c9ff-59g8-m36q and the GitHub Issue #1049 Discussion for technical details on the bypass forms.

Detection Methods for CVE-2026-84218

Indicators of Compromise

Jolokia POST requests containing a target.url field with ldaps://, ldap:// with a non-empty host, or other non-standard JMX service URL variants
Outbound LDAP or LDAPS connections from JVM processes hosting Jolokia to unexpected external hosts
JNDI lookup errors or ClassNotFoundException entries in application logs referencing remote codebases
Unexpected child processes spawned by JVMs running Jolokia agents

Detection Strategies

Inspect web server and reverse-proxy logs for Jolokia POST bodies containing target.url parameters and alert on non-allowlisted schemes or hosts
Correlate JVM process network telemetry with outbound LDAP/LDAPS traffic to identify anomalous destinations
Monitor for Java runtime deserialization activity and reflection following inbound Jolokia requests

Monitoring Recommendations

Enable verbose Jolokia access logging and forward it to a centralized analytics platform for retention and query
Baseline expected outbound destinations for each JVM host and alert on deviations, particularly LDAP protocols
Track Jolokia version inventory across application servers and flag any instance running below 2.6.2

How to Mitigate CVE-2026-84218

Immediate Actions Required

Upgrade Jolokia to version 2.6.2 or later, as documented in the Jolokia Release 2.6.2 Security Fixes notes
Disable the JSR-160 proxy feature if it is not required for operational needs
Restrict network access to Jolokia endpoints so only trusted management hosts can reach them
Rotate any JMX credentials that may have been forwarded through a proxy endpoint during the exposure window

Patch Information

Jolokia 2.6.2 addresses CVE-2026-84218 by tightening validation of target.url values passed to the JSR-160 proxy. Red Hat customers should consult the Red Hat CVE-2026-84218 Advisory and Red Hat Bug Report #2526752 for product-specific fix availability and backports.

Workarounds

Set restrictorClass or Jolokia access policy XML to deny all exec and proxy operations where feasible
Place Jolokia endpoints behind an authenticating reverse proxy and reject POST bodies containing a target.url field
Configure the JVM system property com.sun.jndi.ldap.object.trustURLCodebase=false to prevent remote codebase loading during JNDI lookups
Apply egress firewall rules that block outbound LDAP (389) and LDAPS (636) traffic from application server subnets

bash

# Example jolokia-access.xml restricting proxy usage
<restrict>
  <commands>
    <command>read</command>
    <command>list</command>
  </commands>
  <remote>
    <host>127.0.0.1</host>
  </remote>
</restrict>