CVE-2026-57967

Authorization Bypass
Affects
Apache ActiveMQ Artemis
in
Apache ActiveMQ Artemis
No items found.
Versions
>=1.0.0 <=2.44.0, >=2.50.0 <=2.56.0

Patch Available.

Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

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-57967) has been identified in the CORE protocol handler of Apache ActiveMQ Artemis, which allows attackers to take over another client's authenticated session without presenting any credentials. The hijacked session keeps the victim's identity and permissions, so the attacker can send, consume and manage messages as that user, or close the session to disconnect the victim.

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

Vulnerability Info

This Critical-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. Session reattachment lets a client that lost its connection resume an existing server session on a new one, and that handler's dispatch switch accepts the REATTACH_SESSION packet type:

case PacketImpl.REATTACH_SESSION: {
   ReattachSessionMessage request = (ReattachSessionMessage) packet;
   handleReattachSession(request);
   break;
}

The handler looks the session up by the name the packet supplies and moves it onto the requesting connection:

private void handleReattachSession(final ReattachSessionMessage request) {
   ...
   ServerSessionPacketHandler sessionHandler = protocolManager.getSessionHandler(request.getName());
   if (sessionHandler == null) {
      response = new ReattachSessionResponseMessage(-1, false);
   } else {
      if (sessionHandler.getChannel().getConfirmationWindowSize() == -1) {
         ...
         sessionHandler.closeListeners();
         sessionHandler.close();
         ...
      } else {
         // Reconnect the channel to the new connection
         int serverLastConfirmedCommandID =
            sessionHandler.transferConnection(connection, request.getLastConfirmedCommandID());
         response = new ReattachSessionResponseMessage(serverLastConfirmedCommandID, true);
      }
   }
   channel1.send(response);
}

Neither branch checks who is asking. The connection has not authenticated, and nothing compares it with the connection that originally created the session. transferConnection rebinds the victim's ServerSession, which was created with the victim's credentials, to the attacker's connection, and every later packet on that channel runs with the victim's permissions. Where the victim's channel has no confirmation window (the default), the same request closes the victim's session outright, which gives an unauthenticated attacker a way to disconnect clients.

The attacker needs only TCP access to a CORE acceptor and the name of a live session. 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

Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Critical
ID
CVE-2026-57967
PROJECT Affected
Apache ActiveMQ Artemis
Versions Affected
>=1.0.0 <=2.44.0, >=2.50.0 <=2.56.0
NES Versions Affected
Published date
October 5, 2026
≈ Fix date
October 2, 2026
Category
Authorization Bypass
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Apache ActiveMQ Artemis
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.