CVE-2026-46605
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.
An authorization bypass vulnerability (CVE-2026-46605) has been identified in the Apache ActiveMQ Classic broker's authorization plugin, which allows authenticated users to remove existing queues and topics without holding admin permission on them. Removing a destination discards the messages it holds and disrupts the applications that use it.
Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
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.7, >=6.0.0 <6.2.6
- GitHub repository: https://github.com/apache/activemq
- Published packages:
- Package manager: Maven
- Fixed in:
- OSS Apache ActiveMQ Classic 5.19.7, 6.2.6
- NES for ActiveMQ v5.16.12
Vulnerability Info
This Medium-severity vulnerability is found in the org.apache.activemq:activemq-broker package in multiple versions of Apache ActiveMQ Classic. When a broker is configured with the authorization plugin, AuthorizationBroker decides whether a connection may create or delete a destination by calling checkDestinationAdmin(). That method returns true as soon as the destination already exists, before it looks at the admin ACLs:
protected boolean checkDestinationAdmin(SecurityContext securityContext, ActiveMQDestination destination) {
Destination existing = this.getDestinationMap(destination).get(destination);
if (existing != null) {
return true;
}
if (!securityContext.isBrokerContext()) {
Set<?> allowedACLs = null;
if (!destination.isTemporary()) {
allowedACLs = authorizationMap.getAdminACLs(destination);
} else {
allowedACLs = authorizationMap.getTempDestinationAdminACLs();
}
if (allowedACLs != null && !securityContext.isInOneOf(allowedACLs)) {
return false;
}
}
return true;
}The shortcut makes sense when a client asks to create a destination that is already there, since nothing new is created. However, removeDestination() and removeDestinationInfo() call the same method to authorize deletion:
public void removeDestination(ConnectionContext context, ActiveMQDestination destination, long timeout) throws Exception {
final SecurityContext securityContext = checkSecurityContext(context);
if (!checkDestinationAdmin(securityContext, destination)) {
throw new SecurityException("User " + securityContext.getUserName() + " is not authorized to remove: " + destination);
}
...
super.removeDestination(context, destination, timeout);
}A destination can only be removed if it exists, so for every real removal request the shortcut fires and the admin ACL check is never reached. Any authenticated client, for example one that only has read or write access, can send a destination removal command over OpenWire (such as ActiveMQConnection.destroyDestination()) and delete any existing queue or topic on the broker, along with the messages stored in it.
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
- Leon Johnson (finder)