CVE-2026-67238: RabbitMQ: Atom-table exhaustion via reply-to queue name decoding
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, rabbitpidcodec:decomposefrombinary/1 parses a caller-supplied ETF-encoded binary and calls binarytoatom(Node, utf8) on the node-name field. It is reached from rabbitvolatilequeue:pidfromname/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). binarytoexistingatom 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.7 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.1
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated AMQP 0-9-1 client connected to any vhost can trigger it. The impact is broker-wide: exhausting the Erlang atom table crashes the entire Erlang VM, affecting all vhosts and connections.
What traffic reaches the vulnerable code path?
The vulnerable path is invoked for queue names or routing keys beginning with amq.rabbitmq.reply-to. The client supplies an ETF-encoded value whose node-name field is decoded into a new atom before candidate-node membership is checked.
Are default deployments affected?
A deployment is exposed when an authenticated AMQP 0-9-1 client can perform the required operations and no per-connection rate limit makes roughly one million requests infeasible. The issue applies to RabbitMQ versions before 4.2.7 and 4.3.1.
What can be done if upgrading is not immediately possible?
Restrict AMQP 0-9-1 access to trusted authenticated clients and apply per-connection rate limits low enough to make approximately one million operations infeasible. Because created atoms are never garbage-collected, catching errors after processing does not prevent exhaustion.