CVE-2026-49363

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 information exposure vulnerability (CVE-2026-49363) has been identified in the CORE protocol handler of the Apache ActiveMQ Artemis broker, which allows unauthenticated remote attackers to discover cluster node details by sending a SUBSCRIBE_TOPOLOGY request before authenticating.

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. A CORE client receives cluster topology by sending a SUBSCRIBE_TOPOLOGY or SUBSCRIBE_TOPOLOGY_V2 packet on channel 0, the connection's control channel. Channel 0 is available as soon as the transport handshake completes, before the client creates a session, and the broker checks credentials only when a session is created. The handler in CoreProtocolManager.LocalChannelHandler.handlePacket answers the subscription without checking whether the connection has authenticated:

} else if (packet.getType() == PacketImpl.SUBSCRIBE_TOPOLOGY
   || packet.getType() == PacketImpl.SUBSCRIBE_TOPOLOGY_V2) {
   SubscribeClusterTopologyUpdatesMessage msg = (SubscribeClusterTopologyUpdatesMessage) packet;

   if (packet.getType() == PacketImpl.SUBSCRIBE_TOPOLOGY_V2) {
      channel0.getConnection().setChannelVersion(
         ((SubscribeClusterTopologyUpdatesMessageV2) msg).getClientVersion());
   }

   final ClusterTopologyListener listener = new ClusterTopologyListener() {
      @Override
      public void nodeUP(final TopologyMember topologyMember, final boolean last) {
         ...
         channel0.send(new ClusterTopologyChangeMessage_V4(
            topologyMember.getUniqueEventID(), nodeID,
            topologyMember.getBackupGroupName(),
            topologyMember.getScaleDownGroupName(), connectorPair,
            last, server.getVersion().getIncrementingVersion()));
         ...
      }
      ...
   };

   if (acceptorUsed.getClusterConnection() != null) {
      acceptorUsed.getClusterConnection().addClusterTopologyListener(listener);
      ...
   }

The listener is registered against the broker's live cluster topology, so the broker immediately replays every member it knows about and keeps streaming changes for as long as the connection stays open. Each ClusterTopologyChangeMessage carries the member's node ID, its backup group and scale-down group names, and its live and backup connector configurations, which give the host, port and transport of every clustered broker, including brokers on network segments the attacker cannot reach directly. On a broker that is not clustered, the reply still carries the broker's own node ID. This matters on brokers that run with security enabled and expect every client to authenticate: the attacker needs only TCP access to a CORE acceptor (port 61616 by default) and no credentials. The disclosure affects confidentiality only; it gives no access to messages and no ability to change broker state.

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 the broker's CORE acceptors to trusted client and cluster peer networks, and do not expose them to untrusted networks. Because the topology request is answered before any credentials are checked, treat the addresses of every cluster member as visible to anyone who can reach an acceptor, and firewall those members independently.

When security is enabled (security-enabled=true), NES for Apache ActiveMQ Artemis v2.19.4 withholds the other cluster members and every connector configuration until the client authenticates, but the connected broker's own node ID remains visible before authentication.

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)