CVE-2026-54475

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-54475) has been identified in the Apache ActiveMQ Classic broker's handling of temporary destinations, which allows attackers to consume from a temporary queue or topic created by another connection. Messages meant only for the creating connection, such as replies in a request/reply exchange, can be read or taken by the attacker's consumer.

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.8, >=6.0.0 <6.2.7
• 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.8, 6.2.7
  • NES for ActiveMQ v5.16.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-broker package in multiple versions of Apache ActiveMQ Classic. Temporary queues and topics are meant to be private to the connection that created them, but the broker relies on the client library to enforce this and does not check it itself. A client that speaks to the broker directly, or uses a modified client, can add a consumer on another connection's temporary destination by naming it.

For temporary queues, TempQueue.addSubscription compares the destination's owning connection ID with the subscribing consumer's connection ID. When they differ, it does not reject the consumer. It reassigns ownership of the temporary queue to the subscribing connection and then adds the subscription:

@Override
public void addSubscription(ConnectionContext context, Subscription sub) throws Exception {
    // Only consumers on the same connection can consume from
    // the temporary destination
    // However, we could have failed over - and we do this
    // check client side anyways ....
    if (!context.isFaultTolerant()
            && (!context.isNetworkConnection() && !tempDest
                    .getConnectionId().equals(
                            sub.getConsumerInfo().getConsumerId()
                                    .getConnectionId()))) {

        tempDest.setConnectionId(sub.getConsumerInfo().getConsumerId().getConnectionId());
        LOG.debug("changed ownership of {} to {}", this, tempDest.getConnectionId());
    }
    super.addSubscription(context, sub);
}

For temporary topics, DestinationFactoryImpl.createDestination builds a plain Topic rather than a TempTopic, so no connection check runs at all when a foreign consumer subscribes:

} else if (destination.isTemporary()) {

    Topic topic = new Topic(brokerService, destination, null, destinationStatistics, taskRunnerFactory);
    configureTopic(topic, destination);
    topic.initialize();
    return topic;
}

A temporary destination's name includes the creating connection's ID, and it is commonly sent to other parties in the JMSReplyTo header of request messages. Any client that can open a connection to the broker and learn that name can therefore subscribe to it. On a temporary queue the attacker's consumer competes for messages and takes over ownership of the queue. On a temporary topic it receives a copy of every message published to 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)