CVE-2026-66073: RabbitMQ: Atom table exhaustion via management API node field
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated user with the RabbitMQ management tag and access to at least one vhost can exploit it. This is described as the lowest privilege level required for the affected management API operations.
What is the impact of successful exploitation?
Each request using a unique node value permanently consumes an Erlang atom. Roughly 900,000 such requests can exhaust the atom table, trigger a system_limit VM crash, and interrupt service for all tenants.
Which API operations are implicated?
The affected path includes PUT requests to /api/queues/:vhost/:name and also the exchanges and bindings endpoints when a node JSON field is accepted. The direct request path using get_node/1 is identified as the primary vector.
Which versions contain the fix?
Upgrade to RabbitMQ 3.13.15, 4.0.20, 4.1.11, or 4.2.6. The issue affects releases from 3.13.0 through 3.13.15, as well as the affected 4.0, 4.1, and 4.2 release lines specified in the advisory.