ActiveMQ CVE-2026-34197: 13-Year-Old Jolokia RCE Under Attack

TL;DR

CISA added CVE-2026-34197 to its Known Exploited Vulnerabilities catalog on April 16, giving federal agencies until April 30 to patch. The bug is a remote code execution flaw in Apache ActiveMQ’s Jolokia API that has been sitting in the codebase for about 13 years. It was surfaced last month by Horizon3 researcher Naveen Sunkavally working with Claude, and Fortinet’s FortiGuard team says exploitation peaked on April 14, two weeks after the patch shipped. If you run ActiveMQ 5.x or 6.x and haven’t hit 5.19.4 or 6.2.3 yet, you’re on the scoreboard.

What CISA just flagged

On April 16, CISA added CVE-2026-34197 to its KEV catalog and set the standard 14-day BOD 22-01 deadline. Federal Civilian Executive Branch agencies have until April 30 to apply the patch or stop running affected instances. Private-sector teams aren’t bound by that deadline, but KEV inclusion is CISA’s way of saying the vulnerability isn’t theoretical. Someone is actively dropping shells with it.

ShadowServer’s internet-wide scans count more than 7,500 ActiveMQ brokers exposed to the public internet. How many of those are running a vulnerable version and have Jolokia enabled is a smaller number, but it’s the kind of long tail that never fully goes away. The last time ActiveMQ hit KEV, in late 2023 for CVE-2023-46604, the TellYouThePass ransomware crew used it as a zero-day for weeks. Nothing in the current round of telemetry has been pinned to a specific threat actor yet, but the pattern is familiar.

The bug, in one paragraph

ActiveMQ Classic ships with a Jolokia HTTP endpoint at /api/jolokia/ that lets operators invoke JMX operations over REST. One of those operations, addNetworkConnector(String), accepts a URI. If the URI uses the vm:// transport scheme, ActiveMQ spins up an embedded broker. And that embedded broker honors a brokerConfig=xbean:http://… parameter that tells it to load a remote Spring XML file as its configuration. Spring’s ResourceXmlApplicationContext then instantiates every bean in that XML before ActiveMQ bothers to validate the configuration, which means a MethodInvokingFactoryBean pointing at Runtime.getRuntime().exec() executes on the broker’s JVM before anyone can stop it. That is the entire chain.

Horizon3 rates the authentication requirement as the only real friction: on most versions the attacker needs broker credentials. But admin:admin remains a very common default, and on ActiveMQ 6.0.0 through 6.1.1 a separate earlier bug, CVE-2024-32114, exposes the Jolokia API without auth entirely. Chain those two and the net result is unauthenticated RCE against a meaningful slice of the exposed population.

The attack chain

flowchart LR
    A[Attacker] -->|POST /api/jolokia| B[addNetworkConnector]
    B -->|vm:// URI with brokerConfig| C[Embedded broker boot]
    C -->|xbean:http://attacker/evil.xml| D[Spring XML fetch]
    D -->|MethodInvokingFactoryBean| E[Runtime.exec]
    E --> F[RCE on broker JVM]

Five hops, all using features that are individually benign. Jolokia is a legitimate monitoring tool. addNetworkConnector is a documented operation. The vm:// transport is how ActiveMQ talks to itself. Spring’s XML application context is one of the most heavily used patterns in the Java world. And MethodInvokingFactoryBean is, quite reasonably, the bean you use when you want to call a static method at startup. Put them in the wrong order and you get a decade-plus of remote shell.

How Claude ended up on the disclosure

The Horizon3 writeup opens with a line worth quoting in full: “This was 80% Claude with 20% gift-wrapping by a human.” Naveen Sunkavally didn’t hand Claude a fuzzer or a symbolic execution engine. The model got the ActiveMQ source tree and a rough prompt: where can untrusted input reach code execution? Claude walked the call graph, identified addNetworkConnector as a gadget, followed the vm:// transport into the Spring boot sequence, and flagged MethodInvokingFactoryBean as the exec sink. Sunkavally then did the human work of writing a reproducer, cleaning up the chain, and handling coordinated disclosure.

That’s a second data point on an arc this blog has been tracking. On April 5 we covered Claude Found 500 Zero-Day Vulnerabilities, the Frontier Red Team’s paper where Claude, with nothing more than a VM and standard tools, surfaced hundreds of validated CVEs including a 23-year-old Linux kernel bug. That work was still a research lab result. CVE-2026-34197 is the first time the Claude-found-it, CISA-flagged-it, attackers-are-using-it loop has closed end to end on a single vulnerability, in public.

Thirteen years is a long time for a bug to hide in a project as heavily used as ActiveMQ. Plenty of humans have read the relevant files. The chain sits across five components, and each component’s maintainers reasonably assumed the others were doing validation. An LLM with enough context to hold the whole call graph in working memory at once doesn’t make the same mistake.

Timeline

Seventeen days from patch release to active mass exploitation, nine days from the technical writeup to the CISA listing. Anything with a clean public PoC follows the same rhythm now: reverse-engineer the patch, script the exploit, scan for exposed instances, start spraying. The days when you had a month of grace after disclosure are gone.

Who needs to act, and how

Apache’s fix is in 5.19.4 and 6.2.3. If you’re on 5.18.x or any 6.x below 6.2.3, upgrade. If an upgrade is going to take a maintenance window, the short-term mitigations are the ones you’d expect:

• Block or authenticate the Jolokia endpoint at the reverse proxy layer. Most deployments don’t need /api/jolokia/ exposed to anything outside the ops network. If you can firewall it off, do that first, patch second.
• Rotate broker credentials away from admin:admin and any other shipped defaults. The bug is only unauthenticated on 6.0.0–6.1.1; on every other vulnerable version, a strong password buys you time.
• Add a WAF rule matching request bodies or query strings that contain brokerConfig=xbean:http:// or the vm:// transport scheme. These are the literal strings Horizon3 lists as exploitation indicators. They are not common in legitimate traffic.

For detection: grep broker logs for addNetworkConnector operations invoked over HTTP, and for outbound connections from the broker JVM to addresses the broker has no business talking to (the payload XML is hosted by the attacker, so a broker suddenly fetching XML from a residential IP is a strong signal).

If you don’t actually know whether you have ActiveMQ running anywhere (and at a large enough organization, someone almost always does), a quick nmap sweep on port 8161 plus a search through package inventories for activemq is a reasonable Thursday afternoon.

The bigger pattern

There’s a feedback loop forming that the industry hasn’t figured out yet.

• Frontier labs point LLMs at open-source code and find bugs that have outlived several generations of maintainers.
• Patches ship and get publicly analyzed, usually within a week.
• Attackers, who also have LLMs, rebuild the exploit from patch diffs in hours instead of days.
• CISA adds the CVE to KEV, federal agencies sprint to patch, everyone else either does or doesn’t.

Each loop compresses the timeline. The ActiveMQ case ran from patch to active exploitation in seventeen days. The JetBrains 10,000-developer survey we covered last week showed that a clear majority of developers now use an LLM as part of their daily code-reading workflow. Those same tools are useful both for reviewing a patch diff in good faith and for weaponizing it.

If you’re wiring LLM-assisted code review into your own pipeline, Anthropic’s API console and Anthropic’s published research on Claude’s vulnerability discovery pipeline are the most concrete starting points right now. The same capability that Horizon3 used to find CVE-2026-34197 is available, pretty directly, to the defenders who would rather find their own bugs before the CISA email lands in the Ops inbox at 4 p.m. on a Friday.

FAQ

What is CVE-2026-34197?

A remote code execution vulnerability in Apache ActiveMQ Classic. The bug lets an attacker who can reach the /api/jolokia/ endpoint invoke addNetworkConnector with a crafted URI, causing the broker to load and execute a remote Spring XML configuration file. On vulnerable versions of ActiveMQ 6.x, a separate flaw (CVE-2024-32114) removes the authentication requirement, making the chain unauthenticated.

Which versions of Apache ActiveMQ are affected?

All versions of ActiveMQ Classic released before 5.19.4 (in the 5.x line) and 6.2.3 (in the 6.x line) are affected. Upgrading to those fixed releases patches the bug. The chain is worst on 6.0.0–6.1.1 because the earlier CVE-2024-32114 bug also exposes Jolokia without auth on those builds.

How did Claude find this ActiveMQ vulnerability?

Horizon3 researcher Naveen Sunkavally ran Claude against the ActiveMQ source tree looking for paths from external input to code execution. Claude traced the call graph from the Jolokia-exposed addNetworkConnector operation through the vm:// transport into Spring’s ResourceXmlApplicationContext, and flagged MethodInvokingFactoryBean as the exec sink. Sunkavally wrote the reproducer and disclosed it to Apache on March 22. He credits Claude with about 80% of the work.

Is CVE-2026-34197 being actively exploited?

Yes. Fortinet’s FortiGuard Labs reported exploitation attempts peaking on April 14, 2026, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on April 16. Federal agencies have until April 30 to patch under BOD 22-01. ShadowServer data shows more than 7,500 ActiveMQ brokers still exposed to the public internet.

What is the CVSS score for CVE-2026-34197?

NIST scores CVE-2026-34197 at 8.8 (High). That reflects the authenticated precondition on most versions; on 6.0.0–6.1.1, where authentication falls away via CVE-2024-32114, the real-world impact is closer to a 9.8-class unauthenticated RCE.

Bottom line

Patch to 5.19.4 or 6.2.3 this week. Take Jolokia off the public internet if it’s sitting there. Change any broker that still ships admin:admin. And expect the gap between “LLM finds a 13-year-old bug” and “that bug is in KEV” to keep shrinking. The Horizon3 disclosure landed on April 7, and CISA was flagging active exploitation nine days later. That window isn’t going back up.