CVE-2026-34197: Apache ActiveMQ code execution via the Jolokia API

May 1, 2026By BreachBits Threat Team4 min readHigh severityThreatsAttack surface

The short version: Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge on its web console, and its default policy permits exec operations on broker MBeans. With a crafted discovery URI, an attacker can make the broker load a remote Spring XML context and run code on its JVM (CVE-2026-34197). It's in CISA's KEV catalog. It normally needs an authenticated session — but default credentials, and older builds that expose Jolokia without auth, routinely erase that requirement. Patch and get the console off the internet. Steady hands — but move.

At a glance

Fact	Detail
Our severity take	High — climbing to Critical on internet-exposed or default-credential consoles (see below)
CVSS v3.1 (NVD)	8.8 — High · `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
EPSS	~96.67% · 99.88th percentile (2026-07-16)
In CISA KEV?	Yes — remediation was due 2026-04-30
Known exploited?	Yes — added to KEV; public proof-of-concept exploits exist
Vulnerability type	CWE-94 code injection (via CWE-20 improper input validation) → remote code execution on the broker JVM
Requires authenticated session?	Yes — low-privilege (PR:L); but default creds, and Jolokia exposed without auth on 6.0.0–6.1.1 (CVE-2024-32114), often remove the barrier
Affected	Apache ActiveMQ (Broker / All): before 5.19.4, and 6.0.0 through 6.2.2
Fixed in	5.19.4 · 6.2.3 (or later)

What you need to know

CVE-2026-34197 lives in the Jolokia JMX-HTTP bridge at /api/jolokia/ on the ActiveMQ web console. Jolokia's default access policy allows exec on all ActiveMQ MBeans — including the broker methods that add network connectors. An attacker invokes one of those with a crafted discovery URI that drives the VM transport's brokerConfig parameter to load a remote Spring XML application context. Because Spring instantiates every singleton bean before the broker validates the configuration, arbitrary code runs on the broker's JVM through bean factory methods like Runtime.exec().

The nuance that decides real-world severity is who can reach it:

On paper it's authenticated. The base score reflects a low-privilege session (PR:L), not a fully anonymous attacker.
In practice the gate is often open. ActiveMQ deployments frequently run with the default admin:admin credentials, and builds 6.0.0–6.1.1 expose the Jolokia API without authentication at all (CVE-2024-32114) — turning this into effectively unauthenticated code execution.
The console shouldn't be public. Port 8161 and /api/jolokia/ reaching the internet is the condition that turns "needs a login" into "already exploitable."

How serious we see it

High — and Critical where the console is internet-facing or still on default credentials.

We land at High rather than Critical on paper because exploitation normally requires an authenticated, low-privilege session — a real barrier when the console is locked down and off the internet. But the honest read is that many ActiveMQ consoles aren't: default credentials are common, an older-version auth-bypass can remove the requirement entirely, and the payoff is code execution on the broker. When any of those hold, we treat it as Critical. The bounded, reassuring part: it affects specific versions, the fixes (5.19.4 / 6.2.3) are out, and both patching and restricting the console are firmly in your hands.

Recommendations

Straight from Apache's advisory and CISA:

Patch now. Upgrade to ActiveMQ 5.19.4 / 6.2.3 or later. Confirm you're on a fully patched build rather than a partial fix.
Get the console off the internet. Restrict the web console (port 8161) and /api/jolokia/ to trusted management networks only.
Kill default credentials. Replace admin:admin and any shared logins with strong, unique authentication.
Restrict Jolokia. Where you can, disable or tightly scope Jolokia exec operations.
Hunt. Watch broker logs for network-connector activity referencing vm:// URIs with brokerConfig=xbean:http — an indicator of exploitation attempts.

How BreachRisk sees it

BreachRisk answers the first question — do we have an exposed ActiveMQ broker, and what version? — from the outside in. Starting from little more than your domain, it discovers internet-facing ActiveMQ consoles, fingerprints the product and version, and flags exposure tied to this KEV-listed vulnerability, surfaced at the top of your results because it's in KEV.

That continuous, attacker's-eye view is exactly what a flaw like this rewards: the practical danger depends on whether the console is reachable at all, and BreachRisk's whole starting point is what's reachable from the outside — so an exposed broker is already on your radar, not buried in an internal scan backlog.