Apache ActiveMQ Broker, Jolokia/Spring XML authenticated RCE

Overview

CVE-2026-34197 is a high-severity authenticated remote code execution vulnerability in Apache ActiveMQ Classic, the widely deployed open-source message broker. An authenticated user of the ActiveMQ web console can abuse the embedded Jolokia bridge to make the broker load a remote Spring XML configuration, resulting in arbitrary code execution in the broker's JVM. The CISA ADP / authorised data publisher records a CVSS v3.1 base score of 8.8 (High); the NVD record does not carry a separate NVD-assigned primary value.

The Apache ActiveMQ project published the advisory on the oss-security list and its security page in early April 2026. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 16 April 2026, confirming exploitation in the wild. ActiveMQ has a history of being targeted (notably the unauthenticated CVE-2023-46604), so any RCE in its management surface attracts immediate attacker interest, particularly where consoles are exposed beyond trusted networks.

Technical Details

The vulnerability combines improper input validation (CWE-20) and code injection (CWE-94). ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy is permissive: it permits exec operations on all ActiveMQ MBeans matching org.apache.activemq:*, which includes management operations such as BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String).

An authenticated attacker invokes one of these exec operations through Jolokia with a crafted discovery URI as the argument. The URI triggers ActiveMQ's VM transport, and specifically its brokerConfig parameter, which is designed to bootstrap a broker from a Spring configuration. The supplied value points the loader at a remote Spring XML application context, which ActiveMQ loads using ResourceXmlApplicationContext. The decisive detail is ordering: ResourceXmlApplicationContext instantiates all singleton beans as part of context refresh, and this happens before BrokerService validates the configuration. By defining beans whose factory methods call into the runtime, for example invoking Runtime.exec(), the attacker executes arbitrary commands during bean instantiation, on the broker's JVM, before any validation can reject the configuration.

The requirement is a valid console credential (Privileges Required: Low), but no further user interaction. The flaw affects Apache ActiveMQ (Classic, also published as ActiveMQ All and the Broker artifact) in all versions before 5.19.4 and in the 6.0.0 through 6.2.2 range (from 6.0.0 before 6.2.3).

Impact

• Remote code execution on the ActiveMQ broker JVM, executing with the privileges of the broker process.
• Full compromise of the messaging backbone: interception, forgery, and deletion of messages across all queues and topics the broker serves.
• High loss of confidentiality, integrity, and availability (CIA all High).
• A realistic pivot point into back-end systems, since brokers commonly sit in trusted network segments and hold credentials to connected services.
• Active exploitation in the wild, with the management console as the entry point wherever it is reachable by an attacker who can obtain or guess credentials.

Mitigation

1. Upgrade Apache ActiveMQ to a fixed release: 5.19.4 or later for the 5.x line, or 6.2.3 or later for the 6.x line.
2. If you cannot patch immediately, restrict or disable the Jolokia endpoint: tighten the Jolokia access policy (jolokia-access.xml) to deny exec on management MBeans, or disable the web console entirely where it is not required.
3. Ensure the ActiveMQ web console is never exposed to untrusted networks; bind it to localhost or place it behind a VPN and firewall so only operators can reach /api/jolokia/.
4. Enforce strong, unique authentication on the console and remove any default or shared credentials, since the attack requires only a low-privilege authenticated account.
5. Apply least privilege to the OS account running the broker so that successful code execution is contained, and add egress filtering so the broker cannot fetch a remote Spring XML context from the internet.
6. After upgrading, review configuration and logs for evidence of prior exploitation and rotate any credentials reachable from the broker host.

Detection

The clearest network indicator is Jolokia traffic that performs exec operations against ActiveMQ management MBeans. Inspect web-console and reverse-proxy access logs for requests to /api/jolokia/ whose payload references an exec operation on org.apache.activemq:* MBeans, especially addNetworkConnector or addConnector, and whose arguments contain a discovery URI or a brokerConfig parameter pointing at an external location. Legitimate operators rarely add connectors at runtime via Jolokia, so these requests are inherently high-signal; alert on any of them and capture the full request body where your logging allows.

Because exploitation makes the broker fetch a remote Spring XML document, network egress is a strong secondary signal. Monitor for outbound HTTP/HTTPS connections from the ActiveMQ host to unexpected destinations immediately following a Jolokia request; a broker reaching out to an arbitrary URL to retrieve an XML file is anomalous and maps directly to the ResourceXmlApplicationContext load. Where you can inspect that traffic, the retrieved document will contain Spring bean definitions with factory methods such as Runtime.exec, which is unambiguous.

At the host level, watch the broker JVM for child-process creation. The payload runs during bean instantiation and typically ends in a spawned shell, interpreter, or downloader, so EDR rules that flag the ActiveMQ/Java process launching cmd.exe, powershell, bash, sh, or unexpected binaries will catch successful exploitation even if the Jolokia request was missed. Correlate any such process events with preceding Jolokia console activity to confirm. Review ActiveMQ broker logs for errors around connector or configuration loading, and for stack traces referencing ResourceXmlApplicationContext, which can mark both successful and failed attempts. Finally, validate your version and exposure: inventory ActiveMQ instances against the affected ranges (before 5.19.4, and 6.0.0 through 6.2.2), determine which consoles are network-reachable and by whom, and given KEV listing from April 2026, retain and re-scan console and egress logs from early April 2026 onward for any of the patterns above.