CVE-2026-49364

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-49364) has been identified in the cluster discovery of Apache ActiveMQ Artemis, which allows unauthenticated attackers on the discovery network to capture the broker's cluster administrative credentials during the initial cluster connection handshake. Those credentials can then be used to connect to any broker in the cluster as the cluster user.

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.activemq:artemis-core-client, org.apache.artemis:artemis-server, org.apache.artemis:artemis-core-client
• Affected versions:
  • org.apache.activemq:artemis-server: >=1.0.0 <=2.44.0
  • org.apache.activemq:artemis-core-client: >=1.0.0 <=2.44.0
  • org.apache.artemis:artemis-server: >=2.50.0 <=2.56.0
  • org.apache.artemis:artemis-core-client: >=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.activemq/artemis-core-client, https://central.sonatype.com/artifact/org.apache.artemis/artemis-server, https://central.sonatype.com/artifact/org.apache.artemis/artemis-core-client
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Artemis 2.57.0
  • NES for Apache ActiveMQ Artemis v2.19.4

Vulnerability Info

This Critical-severity vulnerability is found in the org.apache.activemq:artemis-server, org.apache.activemq:artemis-core-client, org.apache.artemis:artemis-server and org.apache.artemis:artemis-core-client packages in multiple versions of Apache ActiveMQ Artemis. When a cluster connection finds its peers through a discovery group, the broker listens for broadcasts on the configured UDP multicast address or JGroups channel and trusts every one it receives. Nothing authenticates the sender of a broadcast. Each advertised node is added to the cluster topology, and the cluster connection responds to the new member by creating a bridge to the connector the broadcast named, handing it the configured cluster user and password:

public void nodeUP(final TopologyMember topologyMember, final boolean last) {
   // ...
   MessageFlowRecord record = records.get(nodeID);

   if (record == null) {
      // New node - create a new flow record
      // ...
      createNewRecord(topologyMember.getUniqueEventID(), nodeID, topologyMember.getLive(), queueName, queue, true);
   }
}

private void createNewRecord(/* ... */) {
   // ...
   ClusterConnectionBridge bridge = new ClusterConnectionBridge(this, manager, targetLocator, serverLocator, /* ... */, clusterUser, clusterPassword, server, /* ... */);
   // ...
}

The bridge then opens its sessions against that connector, sending the credentials in the session-creation packet:

// Session is pre-acknowledge
session = (ClientSessionInternal) csf.createSession(user, password, false, true, true, true, 1);
session.getProducerCreditManager().setCallback(this);
sessionConsumer = (ClientSessionInternal) csf.createSession(user, password, false, true, true, true, 1);

An attacker able to send packets to the discovery endpoint can therefore broadcast a bogus cluster node whose connector points at a host they control. The victim broker connects out to that host and authenticates to it, and the attacker reads the cluster user and password off the wire. The cluster user is a broker-wide administrative principal, so the captured credentials grant full access to every broker that shares them.

The broker initiates the connection, so TLS on its acceptors does not help. The default layout that artemis create --clustered generates uses a discovery group, so a clustered broker is exposed in its default configuration. A cluster connection that lists its peers as static connectors, rather than through a discovery group, is not exposed.

‍

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, replace every discovery group with a static list of peer connectors, or restrict the discovery endpoint to a trusted network. A JGroups channel can authenticate its members with the AUTH protocol and TLS; plain UDP multicast has no sender authentication at all. Releases that contain the fix disable server discovery by default. A broker with any broadcast group or discovery group configured does not start until discovery is enabled again with the system property artemis.discovery.enabled=true or the environment variable ARTEMIS_DISCOVERY_ENABLED=true, and a client locator built on a discovery group fails with AMQ219070. On NES for Apache ActiveMQ Artemis v2.19.4 the broker logs AMQ224097 with AMQ229262 or AMQ229263 as the cause and stays stopped, and an application that embeds the broker gets no exception from start(), so it must check isStarted(). Enabling discovery again restores the exposure, so do so only where the broadcast endpoint authenticates its senders.

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)