Exploitation in the wild of Apache ActiveMQ instances has escalated, security researchers say. Attackers are now chaining two known vulnerabilities to achieve unauthenticated remote code execution.

CVE-2026-34197 was listed in CISA’s Known Exploited Vulnerabilities (KEV) catalogue on April 16. The CVSS 8.8 code injection bug was “hiding in plain sight” for 13 years and found by Horizon3.ai’s Naveen Sunkavally – using what he described as “80% Claude with 20% gift-wrapping by a human.”

Apache’s April 6 security advisory is here. 

It inadvertently exposes the Jolokia (effectively ActiveMQ’s interface) JMX-HTTP bridge at /api/jolokia/ on a web-based management console – although attackers would still require authentication to exploit it. (Default admin:admin user:password setups remain common, Sunkavally said.) 

A second ActiveMQ bug CVE-2024-32114  exposes the Jolokia API without authentication in ActiveMQ versions 6.0.0 (released in November 2023) through to 6.1.1 (June 2024.) This bug is not yet included in KEV and defenders may have missed that the two give full pre-auth RCE. (nb: The versions affected by this particular CVE are considered deprecated.)

Jacob Baines, CTO of VulnCheck said his company is seeing confirmed canary hits based on exploitation of the two bugs – adding this week that “together, the chain creates a low-friction attack path requiring no credentials.”

Jonny Rivera from ActiveState, a software supply chain company, commented: “Apache ActiveMQ is in millions of enterprise stacks.

He added that what makes the bugs dangerous is that many organisations don't know they're running ActiveMQ at all [it is] buried in transitive dependencies, untracked, and nowhere near their patch queue…”

The 2026 CVE already added to KEV has much wider scope.

It affects Apache ActiveMQ Broker: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ All: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ: before 5.19.4, from 6.0.0 before 6.2.3. Users are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue, NVD said.

ActiveMQ exploitation: IOCs?

Horizon3.ai notes that exploitation leaves clear traces in the ActiveMQ broker logs: “Look for network connector activity referencing vm:// URIs with brokerConfig=xbean:http. This is not something that occurs during normal broker operations.”

Defenders/SOC analysts can also look out for POST requests to /api/jolokia/ containing addNetworkConnector in the request body; outbound HTTP requests from the ActiveMQ broker process to unexpected hosts; and unexpected child processes spawned by the ActiveMQ Java process, Sunkavally said in a helpful blog post. 

Because Jolokia provides deep access to your broker's operations (including the ability to delete messages or stop the broker), it is usually restricted by default in production environments, via admin credentials defined in the jetty-realm.properties file of your ActiveMQ installation. As mentioned, often these get forgotten however… Generative AI gives some pretty crisp guidance on identifying if you have ActiveMQ in your stack, and how to check if you are exposed. We’ll let you spin up your own prompts. 

The Stack Sessions: Will AI eat your attack surface and what should you do about it? · Luma
A post-Project Glasswing sanity check on whether “zero day factory” new LLM models should make you wake up in a cold sweat - and what you can do to reduce your…
Ed Targett

The link has been copied!