CVE-2026-42588: Apache ActiveMQ Remote Code Execution via Jolokia Code Injection

Technical summary

CVE-2026-42588 is a code injection flaw in Apache ActiveMQ stemming from improper input validation on the Jolokia JMX-HTTP bridge (exposed at /api/jolokia/). The default Jolokia policy permits exec operations against ActiveMQ MBeans, including BrokerService.addNetworkConnector(). An authenticated attacker can invoke this method with a crafted discovery URI using the "masterslave://" transport scheme, which triggers the broker's VM transport configuration parameter. This parameter leverages Spring's ResourceXmlApplicationContext to load an external or attacker-controlled XML file. Because Spring instantiates all singleton beans—including those with factory methods like Runtime.exec()—before BrokerService validates the configuration, arbitrary code execution occurs in the broker's JVM context. The flaw affects ActiveMQ versions before 5.19.7 and 6.x versions before 6.2.6.

Business impact

Successful exploitation enables an authenticated attacker to execute arbitrary code on the ActiveMQ broker server with the privileges of the ActiveMQ process. In production environments, this typically means the attacker can read/write messages, access message contents, pivot to other systems sharing the broker's network trust, exfiltrate data, deploy malware, or disrupt message queuing operations entirely. Organizations relying on ActiveMQ for critical asynchronous processing, payment systems, order management, or inter-service communication face operational downtime and potential data breach scenarios.

Affected systems

Apache ActiveMQ Broker, Apache ActiveMQ All, and Apache ActiveMQ versions are affected: 5.x branch before version 5.19.7, and 6.x branch before version 6.2.6. The vulnerability requires that Jolokia remain accessible on the web console (default configuration) and that an attacker possess valid authentication credentials to the management interface. Air-gapped or internal-only deployments are still at risk if an insider or compromised internal service has access.

Exploitability

Exploitation requires authentication—an attacker must have valid credentials to access the Jolokia interface. However, this requirement is not a strong protection in practice: many organizations use weak or shared credentials, inherit default credentials, or inadvertently expose the management console to trusted network segments where lateral movement is possible. Once authenticated, the attack is deterministic; no user interaction is needed. The crafted discovery URI can be delivered programmatically. The code injection mechanism is reliable because Spring's bean instantiation is a core framework behavior and cannot be disabled selectively.

Remediation

Organizations should upgrade Apache ActiveMQ to version 5.19.7 or 6.2.6 or later, which fixes the input validation issue and restricts what operations can be performed via Jolokia. Prior to patching, apply network segmentation to restrict access to the ActiveMQ web console (typically port 8161) to only authorized administrator networks. Disable or restrict the Jolokia bridge if not required for operations. Review access logs to identify any suspicious exec invocations. Assume compromise if exploitation is suspected and rotate credentials used by downstream services connecting to ActiveMQ.

Patch guidance

Verify the specific patch versions from the official Apache ActiveMQ security advisory. Apply version 5.19.7 or later for the 5.x branch, or 6.2.6 or later for the 6.x branch. Test patches in a non-production environment first, as ActiveMQ upgrades may require verification of client compatibility and message broker restart procedures. Plan for scheduled downtime; in-place upgrades are typically supported but should be validated. After upgrade, verify that the Jolokia endpoint no longer accepts the malicious masterslave:// URI by testing with a benign discovery configuration.

Detection guidance

Monitor ActiveMQ logs and Jolokia access logs for POST/GET requests to /api/jolokia/ containing "masterslave://" in the URI or request body, especially those targeting BrokerService.addNetworkConnector(). Look for unusual process execution spawned from the ActiveMQ JVM (child processes, outbound network connections, file writes). Network intrusion detection can flag attempts to reach external XML configuration repositories. Correlate authentication events with suspicious Jolokia API calls to identify lateral attack patterns. Review Tomcat or embedded web server logs for 403/401 responses followed by successful authentication attempts.

Why prioritize this

This vulnerability scores 8.1 (HIGH) because it combines authenticated remote code execution with high-impact consequences (confidentiality and integrity violation). The barrier to exploitation is moderate—authentication is required—but ActiveMQ deployments in enterprise messaging environments often have weaker perimeter controls, and compromised internal credentials are common. The attack surface is well-known (Jolokia on the web console), and exploitation is deterministic once credentials are obtained. Organizations should prioritize patching production ActiveMQ brokers within 30 days.

Risk score, explained

CVSS 3.1 score of 8.1 reflects: Network attack vector (immediate remote access), Low attack complexity (no special conditions beyond authentication), Low privileges required (standard user credentials sufficient), no user interaction, no scope change, and high impact on confidentiality and integrity (remote code execution). The score stops short of 9.0+ because the attack requires prior authentication; however, in environments with permissive credential management or internal compromise scenarios, this is a practical risk.

Frequently asked questions