keraattin/cve-2026-34197Detects Apache ActiveMQ Classic RCE (CVE-2026-34197) via Jolokia API with Python and Nmap NSE scripts, checking unauthenticated access and version vulnerability.
A remote code execution vulnerability in Apache ActiveMQ Classic that allows an attacker to execute arbitrary code by invoking the addNetworkConnector(String) MBean operation through the Jolokia API (/api/jolokia/). The attacker embeds a malicious brokerConfig parameter pointing to a remote Spring XML file, which ActiveMQ fetches and parses, instantiating arbitrary Java objects and achieving code execution.
On ActiveMQ versions 6.0.0 through 6.1.1, the Jolokia endpoint is completely unauthenticated, making this a zero-click unauthenticated RCE.
This vulnerability was hidden in the codebase for 13 years before discovery with AI assistance.
| Field | Detail |
|---|---|
| CVE ID | CVE-2026-34197 |
| Vendor | Apache Software Foundation |
| Product | Apache ActiveMQ Classic |
| Affected Versions | All versions before 5.19.4 and 6.2.3 |
| Unauthenticated RCE | Versions 6.0.0 through 6.1.1 (Jolokia has no auth) |
| CVSS v3.1 | 8.8 (High) |
| CWE | CWE-94 — Improper Control of Generation of Code |
| Attack Vector | Network |
| Authentication | Required on 5.x; none on 6.0.0 to 6.1.1 |
| User Interaction | None |
| Exploit Maturity | Public PoC available |
| Patched In | ActiveMQ Classic 5.19.4, 6.2.3 |
| Age of Bug | ~13 years in the codebase |
| Discovery | AI-assisted vulnerability research |
Apache ActiveMQ Classic is one of the most widely deployed open-source message brokers in the Java ecosystem. It implements the Java Message Service (JMS) specification and serves as the backbone of asynchronous communication in thousands of enterprise environments worldwide.
ActiveMQ handles everything from order processing queues and financial transaction pipelines to IoT telemetry streams and microservice event buses. If your organization uses Java-based microservices, event-driven architecture, or any form of asynchronous messaging, there's a good chance ActiveMQ is somewhere in the stack.
ActiveMQ Broker
┌───────────────────────┐
│ │
┌──────────┐ │ ┌───────────────┐ │ ┌──────────┐
│ Producer │───────▶│ │ Message │ │───────▶│ Consumer │
│ (App A) │ send │ │ Queue / │ │ recv │ (App B) │
└──────────┘ │ │ Topic │ │ └──────────┘
│ └───────────────┘ │
┌──────────┐ │ │ ┌──────────┐
│ Producer │───────▶│ ┌───────────────┐ │───────▶│ Consumer │
│ (App C) │ │ │ Jolokia │ │ │ (App D) │
└──────────┘ │ │ API (:8161) │ │ └──────────┘
│ └───────┬───────┘ │
└───────────┼───────────┘
│
⚠️ CVE-2026-34197
Attack surface here
When an attacker compromises ActiveMQ, they don't just get a shell on one server. They sit in the center of every message flow in the organization, able to read, modify, redirect, or inject messages between critical systems.
JMX (Java Management Extensions) is the standard management interface for Java applications. It exposes "MBeans" (Managed Beans) that allow monitoring and control of the application internals. ActiveMQ exposes MBeans for managing brokers, queues, topics, connections, and more.
Jolokia is a JMX-over-HTTP bridge. It translates JMX operations into a RESTful JSON API, making it possible to manage Java applications through HTTP requests rather than requiring a dedicated JMX client.
ActiveMQ Classic ships with Jolokia built in, accessible at /api/jolokia/ on the web console port (default: 8161).
Traditional JMX Access:
┌──────────┐ ┌──────────────┐
│ JConsole │ ────── JMX Protocol ─────────> │ ActiveMQ │
│ │ (requires JMX client) │ MBeans │
└──────────┘ └──────────────┘
Jolokia HTTP Access:
┌──────────┐ ┌──────────────┐
│ curl / │ ── POST /api/jolokia/ ───────> │ ActiveMQ │
│ browser │ (just needs HTTP) │ MBeans │
└──────────┘ └──────────────┘
⬆️
Anyone with HTTP access can
invoke MBean operations
This is where the trouble starts. Jolokia exposes the full power of JMX management through a simple HTTP API. And one of the MBean operations available on the broker is addNetworkConnector(String).
The addNetworkConnector(String) operation is designed to create network bridges between ActiveMQ broker instances. It accepts a URI string describing how to connect to another broker.
ActiveMQ supports a vm:// URI scheme for in-process broker connections. These URIs support a brokerConfig parameter that points to a Spring XML configuration file. And Spring XML can instantiate arbitrary Java objects.
Here's the full chain: