CVE-2026-67238: RabbitMQ: Atom-table exhaustion via reply-to queue name decoding

Severity: medium (CVSS 6.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.3% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-09-23 · updated 2026-10-30
Weakness: CWE-400

Description

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.

Affected products

rabbitmq-server: from 4.2.0 before 4.2.7; from 4.3.0 before 4.3.1 — fixed in 4.2.7, 4.3.1
rabbitmq-server: from 4.2.0, < 4.2.7; from 4.3.0, < 4.3.1

How to fix

Upgrade to a fixed version: rabbitmq-server 4.2.7, 4.3.1. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-67238 or the next vulnerability affects your stack