CVE-2026-66072 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, get_chunk_selector/1 calls binary_to_atom on the raw client-supplied <<"chunk_selector">> property from post-auth subscribe and resolve_offset_spec frames, with no whitelist and no existing guard. An authenticated stream client with read access to any stream can crash the broker node. Preconditions include rabbitmq_stream plugin enabled Authenticated stream-protocol user with read access to at least one stream. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified involves a critical denial of service flaw within the RabbitMQ messaging broker, specifically affecting its stream plugin implementation across multiple version branches including 3.13.x through 4.3.x prior to their respective patch releases. The core technical issue stems from improper handling of user-supplied input during the processing of subscribe and resolve_offset_spec frames in the AMQP 0-9-1 stream protocol. When an authenticated client with read access to a stream initiates these operations, the broker invokes the Erlang function get_chunk_selector/1 which subsequently calls binary_to_atom on the raw chunk_selector property provided by the client. In Erlang and its BEAM virtual machine environment, atoms are not garbage collected and their creation is unbounded if not strictly controlled. The absence of a whitelist or guard clause in this code path allows an attacker to supply arbitrary byte sequences that are converted into new atom names. This behavior directly violates secure coding principles regarding input validation and resource management, leading to the CWE-787 Out-of-bounds Write vulnerability category as well as CWE-20 Improper Input Validation because the system fails to restrict or sanitize incoming data before processing it in a context with severe side effects on memory allocation.
The operational impact of this flaw is severe, resulting in a complete crash of the RabbitMQ broker node rather than merely disrupting individual connections. As each newly created atom consumes memory within the Erlang runtime's atom table without limit, an attacker can rapidly exhaust available system resources by sending a high volume of crafted frames. This resource exhaustion leads to out-of-memory conditions that force the BEAM virtual machine to terminate abruptly. From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability aligns with T1499 Endpoint Denial of Service and potentially T1078 Valid Accounts if pre-authentication access is not required but here specifically requires authenticated stream-protocol user privileges. The attacker must possess read access to at least one stream within a RabbitMQ instance where the rabbitmq_stream plugin is enabled, which narrows the attack surface slightly but still represents a significant risk for organizations relying on persistent streaming capabilities for real-time data ingestion and processing pipelines.
Mitigation strategies primarily involve upgrading to patched versions immediately if possible, specifically version 3.13.15 or later for the 3.13 branch, 4.0.20 or later for the 4.0 branch, 4.1.11 or later for the 4.1 branch, 4.2.6 or later for the 4.2 branch, and 4.3.1 or later for the 4.3 branch. For environments where immediate patching is not feasible due to operational constraints, network-level controls should be implemented to restrict access to RabbitMQ stream ports exclusively to trusted internal subnets and authenticated service accounts with minimal required permissions. Additionally, deploying intrusion detection systems capable of identifying anomalous patterns in AMQP frame sizes or frequencies can help mitigate the rate at which atoms are created, although this is a compensating control rather than a fix. Long-term architectural improvements should include implementing strict input validation layers that enforce allow-listing for all dynamic atom creation scenarios within Erlang-based applications to prevent similar vulnerabilities from arising in future updates or custom extensions of the broker software.