CVE-2026-66073 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, Atom table exhaustion via management API node field. pUT /api/queues/:vhost/:name (and the exchanges and bindings endpoints) accepts a node JSON field. The value goes through rabbitnodes:make → listtoatom with no cluster membership check first. Each unique value permanently leaks one atom. A March 2026 refactoring (ea61ce2563) introduced safe helpers in rabbitmgmtnodes.erl (parsenodename, safeatom, and requirenodename, using binarytoexistingatom) and fixed several callers (QQ replica ops, wmauthattempts, wmnodememoryets, getsortreverse, and rabbitfederationmgmt), but getnode/1 in rabbitmgmtutil.erl:880-885, the primary vector used by directrequest/6, was not Roughly 900K requests crash the VM via systemlimit, and all tenants lose Any user with the management tag and one vhost, the lowest privilege This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
RabbitMQ serves as a widely adopted messaging broker that facilitates asynchronous communication between distributed systems, yet it contains a critical resource exhaustion vulnerability within its management API interface affecting versions from 3.13.0 through 3.13.15 and specific releases in the 4.x series including 4.0.20, 4.1.11, and 4.2.6. The flaw resides in how the system handles node identification fields submitted via HTTP requests to endpoints managing queues, exchanges, and bindings. Specifically, when a client sends an HTTP PUT request to paths such as /api/queues/:vhost/:name, they can include a JSON field specifying a node name. This input is processed by internal Erlang functions that convert the string value into an atom without first verifying whether the specified node actually exists within the cluster or belongs to the requesting tenant. In the Erlang runtime environment, atoms are immutable identifiers that consume memory in a dedicated table known as the Atom Table. Unlike regular heap-allocated objects, atoms cannot be garbage collected once created if they remain referenced, and more critically, there is a hard system limit on the total number of unique atoms allowed per node to prevent out-of-memory conditions.
The technical root cause stems from an incomplete code refactoring performed in March 2026 which introduced safer helper functions like parsenodename, safeatom, and requirenodename that utilize binarytoexistingatom to safely handle atom creation by failing if the atom does not already exist. While this fix was applied to several internal modules including those handling QQ replica operations, authentication attempts, memory tracking, sorting logic, and federation management, a critical oversight left getnode/1 in rabbitmgmtutil.erl unpatched. This function is invoked directly by directrequest/6 during the processing of management API calls. Because it lacks the safety checks present in other parts of the codebase, every unique node name string submitted via the API results in the creation of a new atom that persists for the lifetime of the Erlang VM process. This represents a classic case of improper input validation leading to resource exhaustion, where an attacker can systematically generate distinct strings to fill up the Atom Table until the system limit is reached.
The operational impact of this vulnerability is severe and results in a complete denial of service condition. Once approximately 900,000 unique node names have been submitted through repeated API requests, the Erlang VM hits its atom table limit and crashes entirely. This crash causes all tenants connected to that RabbitMQ instance to lose connectivity immediately, disrupting any dependent services relying on message queuing or streaming capabilities. The vulnerability is particularly dangerous because it requires only minimal privileges to exploit; any user assigned with a management tag and access to at least one virtual host can trigger the flaw. This low barrier to entry means that even compromised service accounts or users with legitimate but limited administrative rights can destabilize the entire messaging infrastructure, leading to significant business disruption and potential data loss if messages are not persisted elsewhere before the crash occurs.
This vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource consumption mechanics, though more accurately it maps to CWE-400 Uncontrolled Resource Consumption as the attacker exhausts a finite system resource (the atom table) through unbounded input processing. From an ATT&CK perspective, this falls under T1499 Endpoint Denial of Service, where the adversary uses techniques to disrupt availability by exhausting resources on targeted systems. Mitigation strategies primarily involve upgrading RabbitMQ to patched versions 3.13.15 or later in the 3.x branch, or version 4.0.20, 4.1.11, or 4.2.6 and newer in their respective branches. For environments where immediate patching is not feasible, administrators should implement strict network-level access controls to restrict management API endpoints to trusted IP addresses only, thereby limiting the attack surface available to potential adversaries. Additionally, enforcing least-privilege principles for user accounts ensures that fewer users have the necessary permissions to interact with these vulnerable endpoints, reducing the risk of exploitation by compromised credentials or insider threats.