Description

An unauthenticated remote attacker can craft a CORE protocol SESSION_REATTACH packet to steal an existing session and assume ongoing execution of the previously authenticated session. This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0. Users are recommended to upgrade to version 2.57.0, which fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-10T05:17:01.443Z",
  "pubdate": "2026-09-10T05:17:01.443Z",
  "executiveSummary": "This vulnerability involves an improper session management flaw within the CORE protocol of Apache ActiveMQ Artemis and Apache Artemis.\nAn unauthenticated, remote attacker can leverage a crafted SESSION_REATTACH packet to hijack an existing, legitimate user session.\nSuccessful exploitation permits the attacker to assume the identity and execution context of the previously authenticated session, effectively bypassing authentication mechanisms.\nThe vulnerability affects Apache Artemis versions 2.50.0 through 2.56.0 and Apache ActiveMQ Artemis versions 1.0.0 through 2.44.0.\nGiven that the attacker requires no prior authentication and can manipulate session continuity, this represents a critical security risk to the confidentiality and integrity of message broker operations, potentially leading to unauthorized data access or malicious message injection.",
  "technicalDetails": "The vulnerability originates in the implementation of the CORE protocol, specifically within the logic governing session reattachment mechanisms. The CORE protocol allows clients to reconnect to an existing session by sending a SESSION_REATTACH packet. The flaw exists because the server fails to properly validate the authenticity or ownership of the reattachment request against the existing authenticated session context.\nExploitation occurs when an attacker crafts a malicious SESSION_REATTACH packet targeting a specific, active session ID. Because the protocol handler does not enforce sufficient cryptographic binding or authentication checks during the reattachment process, the server accepts the attacker's request as legitimate.\nThe attack flow proceeds as follows: 1. The attacker monitors or guesses an active session ID for a connected client. 2. The attacker initiates a connection to the Apache Artemis broker. 3. The attacker transmits a crafted SESSION_REATTACH packet containing the target session ID. 4. The broker, failing to verify the identity of the requester, binds the attacker's connection to the target session. 5. The attacker assumes full control over the hijacked session, gaining the same privileges and authorization level as the original authenticated user.\nThis vulnerability is particularly severe as it requires zero authentication from the attacker and can be performed over the network. The post-exploitation impact allows for arbitrary interaction with the broker as if the attacker were the legitimate client. This includes consuming messages from queues, unauthorized message publishing, and management operations that the hijacked session is authorized to perform. The absence of strict session validation effectively renders authentication controls for the CORE protocol bypassable."
}