CVE-2026-34197

What it actually does

CVE-2026-34197 is an authenticated remote code execution vulnerability in Apache ActiveMQ Classic caused by unsafe exposure of Jolokia JMX-HTTP exec operations through the web console at /api/jolokia/. The default Jolokia access policy permits authenticated users to invoke ActiveMQ MBeans such as BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). By supplying a crafted discovery URI that uses the VM transport brokerConfig parameter, an attacker can cause ActiveMQ to load a remote Spring XML application context. Spring ResourceXmlApplicationContext instantiates singleton beans before ActiveMQ validates the broker configuration, allowing attacker-controlled bean factory methods to execute arbitrary code inside the broker JVM. Successful exploitation can provide the attacker with the same operating-system privileges as the ActiveMQ broker process and can lead to full compromise of message broker confidentiality, integrity, and availability.

Why it matters to the business

A compromised ActiveMQ broker can disrupt messaging-dependent applications, expose sensitive messages, allow manipulation or deletion of queued data, and provide an attacker with a foothold for lateral movement. The risk is elevated because the vulnerability is listed in CISA KEV, has active in-the-wild exploitation, has a very high EPSS score, and has a CISA remediation due date of 2026-04-30. Organizations using affected ActiveMQ versions should treat internet-accessible or broadly reachable web consoles as urgent remediation targets, even though exploitation requires authentication.

How an attack unfolds

An attacker first obtains valid access to the ActiveMQ web console or to the Jolokia endpoint, often through stolen credentials, weak credentials, exposed administrative interfaces, or compromised internal accounts. The attacker then sends an authenticated Jolokia exec request to /api/jolokia/ targeting ActiveMQ BrokerService management operations such as addNetworkConnector or addConnector. Instead of providing a normal connector URI, the attacker supplies a malicious discovery URI that causes the VM transport brokerConfig parameter to reference an attacker-controlled Spring XML configuration. ActiveMQ loads the referenced Spring application context before rejecting or validating the connector configuration. During that load process, Spring instantiates attacker-defined singleton beans, which can invoke dangerous factory methods such as process execution. The payload then runs inside the ActiveMQ JVM, allowing the attacker to deploy a web shell or agent, run commands, download tools, steal message contents or credentials, modify broker configuration, pivot to connected systems, or stop broker services.

How to fix it

Upgrade affected Apache ActiveMQ installations to a fixed version: Apache ActiveMQ Classic 5.x should be upgraded to 5.19.4 or later, and Apache ActiveMQ 6.x should be upgraded to 6.2.3 or later. If immediate upgrade is not possible, restrict access to the web console and /api/jolokia/ to trusted administrative networks only, enforce strong authentication and MFA where supported, remove internet exposure, and update the Jolokia access policy to deny exec operations unless explicitly required. Disable or tightly constrain unused management interfaces. Review broker service account privileges and run ActiveMQ with the least privileges necessary. Rotate ActiveMQ administrative credentials and any secrets available to the broker process if exploitation is suspected. Because this vulnerability is in KEV and actively exploited, compensating controls should be treated as temporary until the software is upgraded.

How to confirm the fix worked

Confirm the installed ActiveMQ version is 5.19.4 or later for the 5.x branch, or 6.2.3 or later for the 6.x branch. Verify that /api/jolokia/ is not exposed to the internet or untrusted networks. Confirm that unauthenticated requests to /api/jolokia/ fail and that authenticated low-privilege users cannot invoke Jolokia exec operations against org.apache.activemq MBeans. Review the Jolokia access policy and confirm that dangerous exec access to BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String) is denied unless strictly required. Validate that no unexpected network connectors, transport connectors, or broker configuration changes were added. Monitor for broker restart stability and ensure applications can still publish and consume messages after the upgrade.

Typical attack path

1. Identify an exposed Apache ActiveMQ Classic web console or Jolokia endpoint at /api/jolokia/.
2. Authenticate with valid credentials or reuse credentials obtained through another compromise.
3. Query Jolokia or the web console to confirm ActiveMQ MBeans are reachable and exec operations are allowed.
4. Submit an authenticated Jolokia exec request invoking BrokerService.addNetworkConnector(String) or BrokerService.addConnector(String).
5. Provide a crafted connector or discovery URI that triggers VM transport brokerConfig loading of a remote Spring XML application context.
6. Cause Spring ResourceXmlApplicationContext to instantiate attacker-controlled singleton beans before ActiveMQ validation occurs.
7. Execute arbitrary commands inside the ActiveMQ broker JVM under the broker service account.
8. Establish persistence, exfiltrate messages or credentials, modify broker configuration, pivot laterally, or disrupt message processing.

How to detect it

Investigate web console access logs, reverse proxy logs, Jolokia request logs, ActiveMQ broker logs, operating-system process telemetry, EDR events, DNS logs, and outbound network flow logs. Look for authenticated POST requests to /api/jolokia/ that invoke exec operations against org.apache.activemq MBeans, especially BrokerService.addNetworkConnector or BrokerService.addConnector. Pay close attention to request bodies or parameters containing brokerConfig, remote HTTP/HTTPS XML references, VM transport URIs, xbean references, or Spring application context loading. In ActiveMQ logs, look for unexpected connector additions, network connector creation, configuration parsing errors, Spring bean instantiation errors, or outbound attempts to fetch remote XML configuration. On the host, hunt for child processes spawned by the ActiveMQ Java process, including command shells, PowerShell, curl, wget, Python, Perl, or other scripting tools. Correlate suspicious Jolokia requests with subsequent outbound network connections from the broker, file writes in ActiveMQ directories or temporary directories, new scheduled tasks or services, and abnormal message deletion, forwarding, or broker downtime. If known threat actor or campaign labels are used internally for this activity, correlate them with the Apache ActiveMQ improper input validation exploitation pattern rather than relying only on static indicators.

• /api/jolokia/
• org.apache.activemq
• addNetworkConnector
• addConnector
• BrokerService.addNetworkConnector
• BrokerService.addConnector
• brokerConfig=
• ResourceXmlApplicationContext
• Runtime.exec
• vm://
• xbean:
• jolokia
• type=Broker
• operation":"exec
• "type":"exec"
• java.lang.ProcessBuilder
• ProcessBuilder
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• Spring XML
• Failed to load ApplicationContext
• Error creating bean with name
• Adding network connector
• Started network connector
• Adding connector

What your security team should do

• Patch all affected ActiveMQ instances to 5.19.4 or 6.2.3 or later as the top priority, especially systems with reachable web consoles or Jolokia endpoints.
• Meet or beat the KEV remediation deadline of 2026-04-30 and prioritize any internet-facing or shared administrative ActiveMQ deployments.
• Immediately restrict /api/jolokia/ and the ActiveMQ web console to trusted administrative networks and remove direct internet exposure.
• Audit Jolokia configuration and deny exec operations against org.apache.activemq MBeans unless there is a documented operational need.
• Search web, proxy, EDR, and ActiveMQ logs for authenticated POST requests to /api/jolokia/ involving addNetworkConnector, addConnector, brokerConfig, or remote Spring XML references.
• Hunt for unexpected child processes spawned by the ActiveMQ Java process, such as shells, PowerShell, curl, wget, or scripting runtimes.
• Review ActiveMQ broker configuration for unauthorized connectors, network connectors, persistence changes, or recently modified configuration files.
• Rotate ActiveMQ administrative credentials and secrets accessible to the broker process if suspicious activity is found.
• Deploy SIEM detections for Jolokia exec requests to ActiveMQ MBeans and for outbound broker connections to unusual HTTP or HTTPS destinations.
• If exploitation is suspected, isolate the broker, preserve logs and memory/disk artifacts, rebuild from trusted media, and restore known-good broker configuration.