CVE-2026-49362

Overview

Apache ActiveMQ Artemis is an open-source, high-performance message broker and the next-generation broker of the Apache ActiveMQ project. It provides asynchronous messaging with a non-blocking, journal-backed core and supports multiple wire protocols and APIs, including AMQP 1.0, MQTT, STOMP, OpenWire, and Jakarta Messaging (JMS). Broker and client components are published as Maven artifacts under org.apache.activemq through 2.44.0, and under org.apache.artemis from 2.50.0.

An authorization bypass vulnerability (CVE-2026-49362) has been identified in the CORE protocol handler of Apache ActiveMQ Artemis, which allows unauthenticated remote attackers to create arbitrary durable queues on the broker. This leads to unauthorized manipulation of broker state and, because every durable queue consumes journal storage and address memory, can deny service to legitimate clients.

Per CWE: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

This issue affects multiple versions of Apache ActiveMQ Artemis.

Details

Module Info

• Product: Apache ActiveMQ Artemis
• Affected packages: org.apache.activemq:artemis-server, org.apache.artemis:artemis-server
• Affected versions:
• org.apache.activemq:artemis-server: >=1.0.0 <=2.44.0
• org.apache.artemis:artemis-server: >=2.50.0 <=2.56.0
• GitHub repository: https://github.com/apache/activemq-artemis
• Published packages: https://central.sonatype.com/artifact/org.apache.activemq/artemis-server, https://central.sonatype.com/artifact/org.apache.artemis/artemis-server
• Package manager: Maven
• Fixed in:
• OSS Apache ActiveMQ Artemis 2.57.0
• NES for Apache ActiveMQ Artemis v2.19.4

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:artemis-server and org.apache.artemis:artemis-server packages in multiple versions of Apache ActiveMQ Artemis. When a CORE connection is accepted, the broker binds an ActiveMQPacketHandler to the connection's control channel (channel 1) immediately, before any authentication takes place; credentials are only checked later, when the client asks to create a session. That handler's dispatch switch accepts the CREATE_QUEUE packet type:

case PacketImpl.CREATE_QUEUE: {
   // Create queue can also be fielded here in the case of a replicated store and forward queue creation
   CreateQueueMessage request = (CreateQueueMessage) packet;
   handleCreateQueue(request);
   break;
}

and passes the packet's fields straight to the broker's internal queue-creation API, which performs no security check:

private void handleCreateQueue(final CreateQueueMessage request) {
   try {
      server.createQueue(new QueueConfiguration(request.getQueueName())
                            .setAddress(request.getAddress())
                            .setFilterString(request.getFilterString())
                            .setDurable(request.isDurable())
                            .setTemporary(request.isTemporary()));
   } catch (Exception e) {
      ActiveMQServerLogger.LOGGER.failedToHandleCreateQueue(e);
   }
}

No user identity, security store lookup or session is involved, so an attacker who opens a TCP connection to a CORE acceptor and sends CREATE_QUEUE packets on channel 1 chooses the queue name, the address, the filter and whether the queue is durable. A failure is only logged and the connection stays open, so the attacker can keep creating queues. Durable queues persist in the journal across broker restarts, which makes the resulting resource exhaustion lasting rather than transient.

Legitimate clients never send this packet on the control channel: the Core client creates queues through its authenticated session channel, where permissions are enforced. CORE is enabled by default on the artemis acceptor on port 61616, so a standalone broker reachable from an untrusted network is exposed in its default configuration.

Mitigation

Only recent versions of Apache ActiveMQ Artemis are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue.

Where upgrading is not immediately possible, restrict network access to every acceptor that accepts the CORE protocol so that only trusted clients and cluster peers can connect.

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache ActiveMQ Artemis to a currently supported release that contains the fix (2.57.0 or later), which upstream publishes under the org.apache.artemis groupId; no fixed release exists under org.apache.activemq.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Domenico Francesco Bruscino (finder)
• Fedrick Sequeira (reporter)
• Mike Read (reporter)
• Tiago Ventura (reporter)