The ActiveMQ RCE on CISA's KEV Will Never Be Patched on Five Version Lines — CVE-2026-34197

By Scott Bissett  ·  Published: August 12, 2026  ·  EOL Watch — news analysis  ·  CVE-2026-34197 · CVSS 8.8 (NVD) · CISA KEV  ·  Verified against CISA's KEV catalog, the Apache ActiveMQ security advisory, and our tracked lifecycle data — methodology

On April 16, 2026, CISA added CVE-2026-34197 — a remote code execution vulnerability in Apache ActiveMQ — to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of April 30. That was almost four months ago. If a broker in your estate is still exposed to this today, it is not because the news hasn't reached you yet — it is almost certainly because the broker runs a version line that the news can't help: one where the fix does not exist and never will.

The vulnerability is reached through ActiveMQ's Jolokia JMX-HTTP bridge — the component that exposes the broker's JMX management operations as HTTP endpoints for the web console. NVD rates it CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): network-reachable, low complexity, no user interaction, full compromise of confidentiality, integrity, and availability. The vector says "privileges required: low" — and here the version lines split into two very different stories. On the 5.x lines, reaching Jolokia requires valid console credentials. On the 6.0 and 6.1 lines, it effectively requires none: the console's Jolokia endpoint sits outside the security constraints — the authentication gap separately tracked as CVE-2024-32114 — so on those lines this is, in practice, an unauthenticated path to code execution on the broker. Apache's fix, per the project's security announcement, shipped in exactly two releases: 5.19.4 and 6.2.3.

And that is the part this article exists for. The affected range — all 5.x releases before 5.19.4, and 6.0.0 up to but not including 6.2.3 — sweeps in five ActiveMQ version lines that are past end of life: 6.1, 6.0, 5.18, 5.17, and 5.16. Apache backports security fixes only to maintained lines, so none of the five will ever see this patch. The two most exposed lines — 6.0 and 6.1, the effectively-unauthenticated ones — are both in that set. If your broker runs any of them, CVE-2026-34197 is not a patching task on your backlog. It is a permanent property of the software until you upgrade.

A message broker sits in the middle on purpose

ActiveMQ's job is to be the connective tissue between systems: order flows, payment events, telemetry, the queues that decouple your services from each other. That is exactly what makes broker compromise expensive. An attacker with code execution on the broker host can read and inject messages on every queue and topic passing through it, reach the internal networks the broker was deliberately given routes into, and harvest the credentials brokers routinely hold — database connections for persistence, LDAP binds, TLS keys. A message broker is rarely internet-facing by design, but it is reachable-by-everything internally by design, and its management console has a long history of being more exposed than its operators assumed.

ActiveMQ has been through this before, and recently. In late 2023, CVE-2023-46604 — an unauthenticated deserialization RCE in the OpenWire transport — went onto CISA's KEV within days of disclosure and was mass-exploited against internet-reachable brokers, including by ransomware operators. The scanning infrastructure that found those brokers did not get dismantled afterward. The KEV listing for CVE-2026-34197 says the same product category is being hunted again — this time through the management console instead of the message transport.

Thirty seconds: which ActiveMQ are you running?

On the broker host:

./bin/activemq --version

Or check the footer of the web console (port 8161 by default). If the answer is 5.19.4/6.2.3 or later on those lines — currently 5.19.10 and 6.2.9 — you are patched against this CVE. Anything else, the next table tells you which of two very different situations you are in. While you are there, ask the second question: who can reach port 8161? On a 6.0 or 6.1 broker, everyone who can is a potential unauthenticated caller of the vulnerable endpoint.

Which versions get a fix — and which are permanently exposed

The affected statement in our Exploited & Unpatchable feed entry, verified against Apache's advisory: all 5.x releases before 5.19.4, and 6.0.0 up to (excluding) 6.2.3. Dates below are from our tracked ActiveMQ lifecycle data, current as of the verification pass on August 12, 2026.

Two rows deserve a second look. First, being on a "supported" line is not the same as being patched — a broker on 6.2.2 or 5.19.3 is inside the affected range until it takes the point update. Second, look at 6.1: it reached end of life on December 2, 2025, about four and a half months before the KEV listing. A broker that was fully patched on 6.1.8 last October is in the permanently-vulnerable set today — and 6.1 is one of the two lines where the vulnerable endpoint is effectively unauthenticated. The line with the worst exposure is also a line where no fix will ever arrive. That combination is why this CVE is in our feed at all.

The upgrade-or-isolate decision

For brokers on a supported line, there is no decision — take the point update to 5.19.4 or later (currently 5.19.10) or 6.2.3 or later (currently 6.2.9) today. It is a maintenance release on a line you are already running, for a CVE that has been on the KEV since April.

For brokers on 6.1, 6.0, 5.18, 5.17, or 5.16, the honest framing is the one from the table: there is no patch for you, and there never will be. The fix for CVE-2026-34197 is not an update you apply — it is an upgrade you undertake. That leaves three moves, in order of preference:

1. Upgrade to a supported line — the real fix. From 6.0 or 6.1, the move to 6.2.3+ is a same-major upgrade and usually the least painful jump in this story. From the 5.16–5.18 lines, 5.19.4+ keeps you on the Classic 5.x series and its familiar configuration surface. Either way, the destination should be a line that still receives security fixes — because this will not be ActiveMQ's last advisory, and the next one will meet the same backport policy.

2. Isolate while the upgrade is scheduled. This CVE has an unusually clean choke point: it lives on the Jolokia JMX-HTTP bridge, which rides the web console listener — port 8161 by default — not the messaging transports. Restrict network access to the console port to an admin network, or disable the web console and Jolokia entirely if nothing depends on them; queues and topics keep flowing without it. On 5.x brokers, exploitation additionally requires valid credentials, so rotate console credentials and stop sharing them. On 6.0/6.1 brokers, do not rely on authentication you may believe the console has — on those lines the vulnerable endpoint sits outside it. That is precisely what "effectively unauthenticated" means.

3. If neither happens now, write it down. A message broker carrying a KEV-listed, actively exploited, never-to-be-patched code execution flaw is a finding under any serious audit framework — and on 6.0/6.1, one with no credential barrier in front of it. A documented risk acceptance with the console lockdown above attached is defensible for the weeks an upgrade takes to land. Silence is not — the federal government's deadline for its own agencies passed on April 30.

The full verified entry — affected statement, KEV dates, fixed versions, and sources to CISA, NVD, and the Apache advisory — is in our Exploited & Unpatchable feed, with a free JSON feed at /exploited-and-unpatchable.json. Every entry is verified against the vendor's own advisory before it goes in; "unpatchable" means the vendor's documentation says so, not that we infer it. We track ActiveMQ and 480+ other products against vendor-verified dates — every ActiveMQ line with live status, or check any version in seconds.

Frequently Asked Questions

Related

• All ActiveMQ versions with live status · ActiveMQ 6.1 — dates and risk score
• Exploited & Unpatchable — the verified feed of KEV-listed vulnerabilities that end-of-life versions will never get fixes for, including this entry
• The TeamCity RCE under active exploitation will never be patched on nine version lines — the same mechanic on a CI server, from the same feed
• Every Jenkins LTS except the newest is now permanently vulnerable — how one advisory strands every out-of-support line at once
• Why End of Life Is Inevitable — the economics behind "fixes ship only in current lines," for every vendor