CVE-2026-27446 Overview
A Missing Authentication for Critical Function vulnerability (CWE-306) has been identified in Apache Artemis and Apache ActiveMQ Artemis message brokers. This critical flaw allows an unauthenticated remote attacker to exploit the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. The consequences of this vulnerability are severe, potentially enabling message injection into any queue and message exfiltration from any queue via the malicious rogue broker.
The vulnerability specifically impacts environments that allow both incoming Core protocol connections from untrusted sources to the broker and outgoing Core protocol connections from the broker to untrusted targets.
Critical Impact
Unauthenticated attackers can hijack broker federation connections to inject or exfiltrate messages from any queue, compromising message integrity and confidentiality in enterprise messaging systems.
Affected Products
- Apache Artemis from 2.50.0 through 2.51.0
- Apache ActiveMQ Artemis from 2.11.0 through 2.44.0
Discovery Timeline
- March 4, 2026 - CVE-2026-27446 published to NVD
- March 5, 2026 - Last updated in NVD database
Technical Details for CVE-2026-27446
Vulnerability Analysis
This vulnerability stems from insufficient authentication controls in the Core protocol implementation of Apache Artemis and Apache ActiveMQ Artemis. The flaw allows unauthenticated remote attackers to manipulate broker federation behavior without proper credential validation, enabling them to redirect outbound connections to malicious endpoints.
When exploited, an attacker can force the vulnerable broker to establish a federation connection to a rogue broker under their control. This attack chain creates a bidirectional threat vector: the attacker can inject malicious messages into legitimate queues (compromising message integrity) while simultaneously exfiltrating sensitive messages from any queue on the target broker (compromising confidentiality). The attack is particularly dangerous because it operates at the protocol level, potentially bypassing application-layer security controls.
Root Cause
The root cause of CVE-2026-27446 is the absence of proper authentication enforcement before establishing Core federation connections. The Core protocol implementation fails to validate the authenticity of federation connection requests, allowing arbitrary connection redirection without credential verification. By default, incoming Core protocol connections are supported via the "artemis" acceptor listening on port 61616, and acceptors without explicit protocol restrictions support all protocols including Core.
Attack Vector
The attack vector is network-based, requiring no user interaction and no prior authentication. An attacker positioned on the network with the ability to send Core protocol messages to the target broker can exploit this vulnerability. The attack flow involves:
- The attacker sends specially crafted Core protocol messages to the vulnerable broker
- The broker interprets these messages as legitimate federation requests
- The broker establishes an outbound Core federation connection to the attacker-controlled rogue broker
- The attacker's rogue broker can then inject messages into or exfiltrate messages from any queue on the target
The vulnerability mechanism involves abusing the Core protocol's federation capabilities to redirect broker connections. When a broker receives federation-related Core protocol commands, it processes them without verifying the authenticity of the requester. An attacker can craft Core protocol messages that instruct the target broker to connect to an arbitrary endpoint. For detailed technical analysis, see the Apache Thread Discussion and Openwall OSS Security Post.
Detection Methods for CVE-2026-27446
Indicators of Compromise
- Unexpected outbound Core protocol connections from the Artemis broker to unknown or suspicious IP addresses
- Unusual federation connection establishment events in broker logs, particularly to non-configured endpoints
- Anomalous message queue activity including unexpected message injection or unexplained message consumption patterns
- Network traffic on port 61616 to destinations not in the approved federation topology
Detection Strategies
- Implement network monitoring rules to detect outbound connections from broker servers to unauthorized endpoints on Core protocol ports
- Configure broker audit logging to capture all federation connection attempts and correlate with known legitimate federation partners
- Deploy intrusion detection signatures to identify malformed or suspicious Core protocol handshake patterns
- Monitor for authentication failures followed by successful federation establishment, which may indicate exploitation attempts
Monitoring Recommendations
- Enable detailed logging for the Artemis acceptor on port 61616 and review logs for unauthorized connection attempts
- Implement network segmentation monitoring to detect broker communication with endpoints outside approved network zones
- Set up alerts for any new federation connections that don't match pre-defined federation topology configurations
- Monitor message queue metrics for unusual patterns such as unexpected message counts or throughput anomalies
How to Mitigate CVE-2026-27446
Immediate Actions Required
- Upgrade to Apache Artemis version 2.52.0, which contains the security fix for this vulnerability
- Audit current acceptor configurations to identify which acceptors support Core protocol from untrusted sources
- Implement two-way SSL certificate-based authentication on all acceptors as an immediate protective measure
- Review and restrict firewall rules to limit incoming connections on port 61616 to trusted sources only
Patch Information
Apache has released version 2.52.0 of Apache Artemis which addresses this vulnerability. Users running affected versions should upgrade immediately. Additional technical details and discussion can be found in the Apache Thread Discussion, the Openwall OSS Security Post, and the Openwall OSS Security Update.
Workarounds
- Remove Core protocol support from any acceptor receiving connections from untrusted sources by configuring the protocols URL parameter for the acceptor to explicitly exclude Core protocol
- Implement two-way SSL (certificate-based authentication) to force every client to present a valid SSL certificate before any message protocol handshake is attempted
- Deploy network-level access controls to ensure only trusted systems can establish connections to broker acceptors
- Segment broker infrastructure to separate internal broker communication from externally-facing endpoints
<!-- Example acceptor configuration to restrict protocols (remove Core) -->
<acceptor name="artemis">
tcp://0.0.0.0:61616?protocols=AMQP,MQTT,STOMP;sslEnabled=true;keyStorePath=/path/to/keystore.jks;keyStorePassword=changeit;trustStorePath=/path/to/truststore.jks;trustStorePassword=changeit;needClientAuth=true
</acceptor>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

