2. Root Cause

2.1 Attack Chain

2.2 Key Conditions

1. Jolokia API exposure - The ActiveMQ Web Console exposes /api/jolokia/, providing JMX-over-HTTP access.
2. Overbroad MBean allowlist - The CVE-2022-41678 fix introduced an allowlist that permits broad org.apache.activemq:* operations, including addNetworkConnector.
3. VM Transport remote configuration - The brokerConfig parameter of the vm:// transport can point to remote Spring XML, and bean instantiation happens before the configuration is rejected.

2.3 Fix Behavior

ActiveMQ 6.2.3 added validation inside addNetworkConnector() to reject vm:// transport URIs:

3. Reproduction

3.1 Environment

3.2 Steps

Step 1: Start the lab

Step 2: Verify the Jolokia API

A status: 200 response confirms that Jolokia is reachable.

Step 3: Run the exploit and write a webshell

The script performs the following actions:

1. Checks the Jolokia API.
2. Discovers the broker name.
3. Removes an existing NetworkConnector named NC to make repeated testing reliable.
4. Starts a local HTTP server that serves a malicious Spring XML payload. The JSP webshell is embedded as base64, so the target only needs to fetch the XML once.
5. Sends an addNetworkConnector request to trigger the vulnerable code path.
6. Verifies that the webshell was written successfully.

Step 4: Use the webshell

3.3 Sample Output

4. Version Comparison

5. Exploitation Notes and Limitations

5.1 Repeated Exploitation

addNetworkConnector() registers a connector named NC. A second registration fails with a JMX naming conflict and returns a 500 error. The script handles this by calling removeNetworkConnector("NC") before triggering the exploit.

5.2 Webshell Write

ActiveMQ uses embedded Jetty, but the webapps directory exists on disk and the JSP engine compiles newly written .jsp files. This makes webshell writing possible in the tested environment.

The payload writes the JSP using inline base64:

Benefits:

• Avoids XML parsing issues caused by JSP special characters such as <, >, %, and ".
• Avoids a second outbound request from the target to download the JSP. The target only fetches the XML payload.

5.3 Outbound Network Requirement

The target must be able to reach the attacker-controlled HTTP server to fetch the Spring XML payload. If the target has no outbound route to the attacker, this exploit path cannot complete.

5.4 Jolokia Origin Check

Direct Jolokia requests may return 403 due to CORS checks. Include an Origin header that matches the target:

6. Files

Script Comparison

7. Mitigation

1. Upgrade - Upgrade to ActiveMQ Classic 5.19.4+ or 6.2.3+.
2. Restrict Jolokia access - Limit access to port 8161 with firewall rules or network policy.
3. Disable Jolokia - If remote JMX management is not required, disable the Jolokia API in jetty.xml.
4. Change default credentials - Replace the default admin:admin credentials.
5. Restrict outbound access - Prevent ActiveMQ from reaching untrusted external HTTP resources.

8. References

• Horizon3.ai disclosure: https://horizon3.ai/attack-research/disclosures/cve-2026-34197-activemq-rce-jolokia/
• Apache security advisory: https://activemq.apache.org/security-advisories.data/CVE-2026-34197-announcement.txt
• Original PoC repository: https://github.com/dinosn/CVE-2026-34197