CVE-2026-67238 in RabbitMQ
Summary
by MITRE • 09/23/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, rabbit_pid_codec:decompose_from_binary/1 parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. It is reached from rabbit_volatile_queue:pid_from_name/2, which is invoked for any queue name / routing key beginning amq.rabbitmq.reply-to.. The CandidateNodes membership check happens after the atom is created, and the surrounding try/catch cannot reclaim atoms (they are never GC'd). binary_to_existing_atom is not used. Any authenticated AMQP client can crash the entire Erlang VM (all vhosts, all connections) with ~1M cheap requests. Preconditions include Authenticated AMQP 0-9-1 connection to any vhost No per-connection rate limit low enough to make ~1M operations infeasible. This issue is fixed in versions 4.2.7 and 4.3.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified involves a critical resource exhaustion flaw within RabbitMQ, specifically affecting the handling of AMQP protocol messages before version 4.2.7 and 4.3.1. The core technical issue resides in the rabbit_pid_codec:decompose_from_binary/1 function, which is responsible for parsing Erlang Term Format encoded binaries sent by clients. When processing queue names or routing keys that begin with amq.rabbitmq.reply-to., this function invokes binary_to_atom(Node, utf8) on the node-name field extracted from the message payload. This specific API call creates a new atom in the Erlang VM if it does not already exist, rather than checking for an existing one as would be done with binary_to_existing_atom/2. In the Erlang runtime system, atoms are stored in a global table and are never garbage collected once created. Consequently, each unique string passed to this function results in a permanent allocation of memory that cannot be reclaimed by the virtual machine during its normal operation cycle.
The operational impact of this flaw is severe, leading to a Denial of Service condition against the entire RabbitMQ cluster or node. Because atoms are never garbage collected, an attacker can systematically exhaust the atom table limit of the Erlang VM by sending a large number of distinct queue names starting with amq.rabbitmq.reply-to.. The vulnerability allows any authenticated AMQP client to trigger this behavior without requiring elevated privileges beyond standard authentication. Once the atom table is filled, the Erlang VM becomes unable to create new atoms for internal operations, leading to crashes across all vhosts and connections managed by that node. This effectively renders the messaging broker unavailable until it is restarted or the underlying memory issue is resolved through a patch update. The attack requires approximately one million requests to trigger, which can be executed relatively cheaply if there are no per-connection rate limits configured low enough to prevent such volume in a feasible timeframe.
From a security classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write and more specifically CWE-400: Uncontrolled Resource Consumption. The failure to use binary_to_existing_atom/2 instead of binary_to_atom/1 represents an improper input validation mechanism that fails to account for the persistent nature of atom creation in Erlang. In terms of attack vectors, this falls under ATT&CK technique T1498: Network Denial of Service, as it involves overwhelming a resource with requests to disrupt service availability. The precondition for exploitation includes having an authenticated AMQP 0-9-1 connection to any vhost and the absence of sufficient rate limiting controls on individual connections. This highlights the importance of implementing strict input validation and using safe API functions that prevent unbounded growth of internal data structures when processing user-supplied binary data.
Mitigation strategies primarily involve upgrading RabbitMQ to version 4.2.7 or later, where this issue has been resolved by correcting the atom creation logic to use binary_to_existing_atom/2 or similar safe alternatives that do not leak memory on every unique input. Additionally, organizations should implement robust rate limiting policies at both the connection and per-connection levels to mitigate the volume of requests an authenticated client can send in a short period. Network-level controls such as firewalls or intrusion prevention systems configured to detect high-frequency AMQP traffic patterns associated with this specific queue name prefix can also provide an additional layer of defense against exploitation attempts while patching is being applied. Regular auditing of authentication mechanisms and input validation routines for messaging brokers is essential to prevent similar resource exhaustion vulnerabilities in distributed system architectures.