CVE-2026-34197: Apache ActiveMQ RCE Vulnerability

CVE-2026-34197 Overview

CVE-2026-34197 is an Improper Input Validation and Code Injection vulnerability affecting Apache ActiveMQ Broker and Apache ActiveMQ. The vulnerability exists in the Jolokia JMX-HTTP bridge exposed at /api/jolokia/ on the web console. Due to an overly permissive default Jolokia access policy that permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), an authenticated attacker can invoke sensitive operations including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String) with crafted discovery URIs.

The attack leverages the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().

Critical Impact

Authenticated attackers can achieve arbitrary code execution on the Apache ActiveMQ broker's JVM by exploiting the Jolokia JMX-HTTP bridge to load malicious Spring XML configurations, potentially leading to complete system compromise.

Affected Products

• Apache ActiveMQ Broker: versions before 5.19.4 and from 6.0.0 before 6.2.3
• Apache ActiveMQ All: versions before 5.19.4 and from 6.0.0 before 6.2.3
• Apache ActiveMQ: versions before 5.19.4 and from 6.0.0 before 6.2.3

Discovery Timeline

• 2026-04-07 - CVE-2026-34197 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-34197

Vulnerability Analysis

This vulnerability represents a dangerous code injection flaw that chains multiple weaknesses to achieve remote code execution. The root issue stems from insufficient input validation when processing discovery URIs through the Jolokia JMX-HTTP bridge.

Apache ActiveMQ Classic exposes the Jolokia endpoint at /api/jolokia/ which provides a REST interface to JMX operations. The default security policy is overly permissive, allowing exec operations across all ActiveMQ MBeans. This enables authenticated users to call sensitive broker management methods that were not intended to be exposed via HTTP.

The attack flow begins when an attacker invokes BrokerService.addNetworkConnector(String) or BrokerService.addConnector(String) via Jolokia with a specially crafted VM transport URI containing a brokerConfig parameter pointing to an attacker-controlled Spring XML configuration file.

When Spring's ResourceXmlApplicationContext processes this malicious configuration, it instantiates all defined singleton beans immediately, before ActiveMQ has a chance to validate the configuration. This timing allows attackers to define bean factory methods such as Runtime.exec() that execute arbitrary commands on the broker's JVM.

Root Cause

The vulnerability is caused by the combination of an overly permissive default Jolokia access policy and insufficient validation of the brokerConfig parameter in VM transport URIs. The policy allows exec operations on all ActiveMQ MBeans without restricting access to sensitive broker management methods. Additionally, the use of ResourceXmlApplicationContext for loading configuration files creates a code execution vector when combined with attacker-controlled input, as Spring eagerly instantiates beans before any validation occurs.

Attack Vector

The attack is network-based and requires low-privileged authenticated access to the ActiveMQ web console. An attacker with valid credentials can send HTTP requests to the /api/jolokia/ endpoint to invoke JMX operations. The exploitation process involves:

1. Authenticating to the ActiveMQ web console
2. Crafting a malicious Spring XML configuration hosted on an attacker-controlled server
3. Sending a request to Jolokia to invoke BrokerService.addNetworkConnector() with a VM transport URI containing a brokerConfig parameter pointing to the malicious XML
4. The Spring framework loads and processes the XML, instantiating malicious beans that execute arbitrary code

The vulnerability mechanism involves crafting a discovery URI that triggers the VM transport to load an external Spring XML application context. When the ResourceXmlApplicationContext processes this configuration, bean factory methods like Runtime.exec() are invoked during initialization, executing attacker-supplied commands before any security validation occurs. For detailed technical information, see the Apache ActiveMQ Security Advisory.

Detection Methods for CVE-2026-34197

Indicators of Compromise

• Unusual HTTP requests to /api/jolokia/ endpoints containing exec operations targeting org.apache.activemq:* MBeans
• Requests containing VM transport URIs with brokerConfig parameters pointing to external URLs
• Outbound network connections from the ActiveMQ broker process to unexpected external hosts
• Unexpected child processes spawned by the ActiveMQ JVM process

Detection Strategies

• Monitor HTTP access logs for requests to /api/jolokia/ containing patterns like addNetworkConnector, addConnector, or brokerConfig
• Implement network monitoring to detect the ActiveMQ broker making outbound HTTP/HTTPS requests to fetch external XML files
• Deploy endpoint detection to identify unusual process spawning from the Java process running ActiveMQ
• Audit authentication logs for suspicious login patterns to the ActiveMQ web console

Monitoring Recommendations

• Enable detailed access logging for the ActiveMQ web console and Jolokia endpoint
• Configure SIEM rules to alert on Jolokia exec operations targeting broker management MBeans
• Implement egress filtering to restrict outbound connections from message broker systems
• Monitor JMX operations for calls to sensitive broker management methods

How to Mitigate CVE-2026-34197

Immediate Actions Required

• Upgrade Apache ActiveMQ to version 5.19.4 or 6.2.3 immediately
• Restrict network access to the ActiveMQ web console and Jolokia endpoint to trusted administrative networks only
• Review and restrict Jolokia access policies to deny exec operations on sensitive MBeans
• Audit recent access logs to the /api/jolokia/ endpoint for signs of exploitation attempts

Patch Information

Users are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue. The patched versions implement proper input validation for discovery URIs and restrict the Jolokia access policy to prevent exec operations on sensitive broker management MBeans. For additional details, refer to the Apache ActiveMQ Security Advisory and the OpenWall OSS Security Discussion.

Workarounds

• Disable the Jolokia endpoint entirely if JMX-over-HTTP functionality is not required
• Configure a restrictive Jolokia access policy that denies exec operations on org.apache.activemq:* MBeans
• Place the ActiveMQ web console behind a reverse proxy with strict authentication and IP whitelisting
• Implement network segmentation to isolate message broker systems from untrusted networks

# Example: Restrict Jolokia access in jolokia-access.xml
# Place this configuration in the ActiveMQ conf directory
# Deny exec operations on broker management MBeans
cat > conf/jolokia-access.xml << 'EOF'
<restrict>
  <commands>
    <command>read</command>
    <command>list</command>
    <command>search</command>
    <!-- exec command intentionally omitted to deny execution -->
  </commands>
  <deny>
    <mbean>
      <name>org.apache.activemq:*</name>
      <operation>addNetworkConnector</operation>
      <operation>addConnector</operation>
    </mbean>
  </deny>
</restrict>
EOF