CVE-2026-61487
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-61487) has been identified in the ActiveMQ Classic broker's AuthorizationBroker, which allows an authenticated low-privilege user to publish messages to queues or topics they have no write permission for. The user does this by sending to a temporary composite destination whose components are real destinations.
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.9, >=6.0.0 <6.2.8
- GitHub repository: https://github.com/apache/activemq
- Published packages:
- Package manager: Maven
- Fixed in:
- OSS Apache ActiveMQ Classic 5.19.9, 6.2.8, 6.3.0
- 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 the broker is configured with an authorization plugin, AuthorizationBroker decides which ACLs apply to a destination by checking only whether the destination is temporary. Every temporary destination is checked against the single set of temporary-destination ACLs, and the per-destination ACLs are never consulted:
@Override
public void send(ProducerBrokerExchange producerExchange, Message messageSend) throws Exception {
final SecurityContext securityContext = checkSecurityContext(producerExchange.getConnectionContext());
if (!securityContext.isBrokerContext() && !securityContext.getAuthorizedWriteDests().containsValue(messageSend.getDestination())) {
Set<?> allowedACLs = null;
if (!messageSend.getDestination().isTemporary()) {
allowedACLs = authorizationMap.getWriteACLs(messageSend.getDestination());
} else {
allowedACLs = authorizationMap.getTempDestinationWriteACLs();
}
if (allowedACLs != null && !securityContext.isInOneOf(allowedACLs)) {
throw new SecurityException("User " + securityContext.getUserName() + " is not authorized to write to: " + messageSend.getDestination());
}
securityContext.getAuthorizedWriteDests().put(messageSend.getDestination(), messageSend.getDestination());
}
super.send(producerExchange, messageSend);
}An ActiveMQ destination can be a composite: its physical name is a comma-separated list, and the broker delivers a message sent to it to each listed destination. A client controls both the destination type and its name, so it can mark a composite of real queues or topics as temporary. Because the composite is temporary, the check above compares the user only against the temporary-destination write ACLs. The write ACLs of the real queues and topics in the composite are never evaluated, and the message is delivered to all of them. addProducer, addConsumer and checkDestinationAdmin use the same temporary-only branch for write, read and admin checks.
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
- Claude and Ada Logics (finder)