Researchers: Jolokia component behind ActiveMQ RCE traces to a 13‑year‑old flaw

Apache ActiveMQ Classic has a new remote-code-execution bug, but the weird part is its age. The issue, tracked as CVE-2026-34197, was disclosed on April 7, 2026, and the exploit path appears to have been sitting in the product for roughly 13 years. The stakes are simple — if an attacker can reach the right management endpoint, they can make the broker run commands on the host. And in some versions, a second flaw strips away authentication entirely. ### What is Jolokia doing here? Jolokia is the HTTP bridge that lets ActiveMQ’s web console talk to JMX management functions. In ActiveMQ Classic, that bridge lives at `/api/jolokia/` and exposes broker operations over the web console on port 8161. That sounds administrative — because it is — but administrative surfaces become attack surfaces the second they are reachable from the wrong place. ### So what actually breaks? The dangerous operation is an MBean call like `addNetworkConnector(String)` or `addConnector(String)`. An attacker can feed it a crafted discovery URI that makes the broker load a remote Spring XML configuration through `ResourceXmlApplicationContext`. Spring then instantiates beans before ActiveMQ finishes validating, the broker gets tricked into treating attacker-controlled config as something safe to initialize. ### Why are researchers calling it 13 years old? Because this is not a brand-new module gone wrong. Horizon3 says the exploit path has been “hiding in plain sight” for 13 years, and the reason it lasted that long is that the bug sits at the intersection of several legitimate features — Jolokia, ActiveMQ MBeans, network connectors, VM transport, and the chain end to end. ### Wasn’t Jolokia already tightened before? Yes — and that’s part of why this is messy. After an earlier Jolokia-related bug, ActiveMQ restricted Jolokia by default and blocked dangerous MBeans, but it kept a broad allow rule for ActiveMQ’s own MBeans so the console would still work. CVE-2026-34197 abuses that exact carve-out. In other words, the “safe” exception turned out to include a path back to code execution. ### Is this authenticated or not? Officially, CVE-2026-34197 is an authenticated flaw. But that description understates the real-world risk. ActiveMQ 6.x before 6.1.2 had another bug, CVE-2024-32114, where the API web context — including Jolokia — was not secured by default. On versions 6.0.0 through 6.1.1, that means the new flaw can effectively become unauthenticated no matter. ### Which versions need attention? Apache says CVE-2026-34197 affects ActiveMQ Classic before 5.19.4 and 6.0.0 before 6.2.3. But there’s already a follow-on advisory — CVE-2026-40466 — for a bypass involving HTTP discovery when the `activemq-http` module is present. The newer fixed versions for that bypass are 5.19.6 and 6.2.5. So if a team stopped at the first patch, it may still have work to do. ### Is anyone actually exposed? Yes. Shadowserver counted more than 6,400 internet-exposed ActiveMQ servers vulnerable to ongoing attacks in April, and CISA added CVE-2026-34197 to its Known Exploited Vulnerabilities catalog. That matters because ActiveMQ has a long history of being hit in the wild — older flaws like CVE-2016-3088 and CVE-2023-46604 already made that clear. ### What’s the bottom line? Treat Jolokia like a public-facing risk, not an internal convenience. If you run ActiveMQ Classic, inventory exposed `/api/jolokia/` endpoints, patch past both CVE-2026-34197 and its bypass, lock down the web console, and check logs for suspicious `vm://` or `brokerConfig=xbean: activity. assumptions around them.