CVE-2026-45505
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 and Enterprise Integration Patterns server maintained by the Apache Software Foundation. It supports the OpenWire, STOMP, AMQP 1.0 and MQTT protocols, fully supports JMS 1.1, and can be embedded in and configured through Spring applications. The broker, client and web console modules are published as Maven artifacts under org.apache.activemq.
A remote code execution vulnerability (CVE-2026-45505) has been identified in the ActiveMQ broker's JMX management interface, which allows authenticated attackers to bypass the transport scheme check on the addConnector and addNetworkConnector operations and execute arbitrary code on the broker's JVM. The flaw lets discovery wrappers written without parentheses, such as masterslave:vm://... and static:vm://..., slip a denied vm transport past the protection 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 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 multiple versions of ActiveMQ. The broker's BrokerView MBean exposes addConnector(String) and addNetworkConnector(String), which the web console's Jolokia JMX-HTTP bridge at /api/jolokia/ lets an authenticated user invoke. If the supplied discovery URI reaches a VM transport, its brokerConfig parameter can make the broker load a remote Spring XML application context, and Spring instantiates every singleton bean in it, so a bean factory method such as Runtime.exec() runs attacker-chosen code before the configuration is ever validated.
The fix for CVE-2026-34197 rejects such URIs by checking each scheme against a deny list. That check only descends into a URI when URISupport.isCompositeURI reports it as composite:
private static void validateAllowedUri(URI uri, int depth) throws URISyntaxException {
if (depth > 4) {
throw new IllegalArgumentException("URI can't contain more than 5 nested composite URIs");
}
// First check the main URI scheme
validateAllowedScheme(uri.getScheme());
// If composite, iterate and check each of the composite URIs
if (URISupport.isCompositeURI(uri)) {
URISupport.CompositeData data = URISupport.parseComposite(uri);
depth++;
for (URI component : data.getComponents()) {
if (URISupport.isCompositeURI(component)) {
validateAllowedUri(component, depth);
} else {
validateAllowedScheme(component.getScheme());
}
}
}
}isCompositeURI returns true only when the scheme-specific part starts with ( and the parentheses balance:
public static boolean isCompositeURI(URI uri) {
String ssp = stripPrefix(uri.getRawSchemeSpecificPart().trim(), "//").trim();
if (ssp.indexOf('(') == 0 && checkParenthesis(ssp)) {
return true;
}
return false;
}Parentheses are optional when writing ActiveMQ's composite and nested URIs, so wrappers such as static:vm://... and masterslave:vm://...,... are still accepted by the transports without them. For such a URI only the outer scheme is checked. That scheme is not on the deny list, so the nested vm:// component carrying the malicious brokerConfig is never inspected and is passed straight to brokerService.addNetworkConnector or brokerService.addConnector. Older releases that predate the CVE-2026-34197 fix, such as the 5.16.x line, perform no scheme validation on these operations at all.
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
- lokerxx (finder)