CVE-2026-40466
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache ActiveMQ Classic is an open-source Java message broker that provides asynchronous messaging for applications. It supports JMS 1.1 and multiple wire protocols, including OpenWire, AMQP, MQTT and STOMP. Broker and client components are published as Maven artifacts under org.apache.activemq. ActiveMQ Classic is distinct from Apache ActiveMQ Artemis, which has its own broker implementation and release lines.
A remote code execution vulnerability (CVE-2026-40466) has been identified in the JMX connector management operations of the Apache ActiveMQ Classic broker, which allows authenticated attackers to run arbitrary code on the broker's JVM. An attacker who can call BrokerView.addConnector or BrokerView.addNetworkConnector through Jolokia can supply an HTTP discovery transport URI that bypasses the validation added for CVE-2026-34197.
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 Apache ActiveMQ Classic.
Details
Module Info
- Product: Apache ActiveMQ Classic
- Affected packages:
org.apache.activemq:activemq-broker,org.apache.activemq:activemq-all,org.apache.activemq:apache-activemq - Affected versions: <5.19.6, >=6.0.0 <6.2.5
- GitHub repository: https://github.com/apache/activemq
- Published packages: https://central.sonatype.com/artifact/org.apache.activemq/activemq-broker, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all, https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq
- Package manager: Maven
- Fixed in:
- OSS Apache ActiveMQ Classic 5.19.6, 6.2.5
- NES for ActiveMQ v5.16.10
Vulnerability Info
This High-severity vulnerability is found in the org.apache.activemq:activemq-broker package in multiple versions of Apache ActiveMQ Classic. The broker's BrokerView MBean exposes addConnector and addNetworkConnector, which pass an attacker-supplied discovery address to BrokerService. The validation introduced for CVE-2026-34197 only rejects a URI, or a component of a composite URI, whose scheme is vm:
// We don't allow VM transport scheme to be used
private static void validateAllowedScheme(String scheme) {
if (scheme.equals("vm")) {
throw new IllegalArgumentException("VM scheme is not allowed");
}
}Releases that predate that validation, such as the 5.16.x line, pass the address straight through with no scheme check at all:
public String addNetworkConnector(String discoveryAddress) throws Exception {
NetworkConnector connector = brokerService.addNetworkConnector(discoveryAddress);
...
connector.start();
return connector.getName();
}When the activemq-http module is on the classpath, an http discovery URI passes this check. The HTTP discovery agent then fetches the registry URL and treats every non-blank line of the response as a service URI to connect to, so a malicious HTTP endpoint can answer with a vm:// URI that was never validated. The attacker uses that VM transport's brokerConfig parameter to point at a remote Spring XML file, which the broker loads with ResourceXmlApplicationContext. Because Spring instantiates all singleton beans before BrokerService validates the configuration, bean factory methods such as Runtime.exec() run arbitrary code in the broker's JVM. The attacker needs credentials that allow JMX operations through Jolokia.
Mitigation
Inactive versions of Apache ActiveMQ Classic are End-of-Life and will not receive updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade affected applications to a currently supported release of Apache ActiveMQ Classic that contains the fix.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- Fatih Ersinadim (finder)
- gggggggga (finder)