All vulnerabilities
CVE-2026-67238GHSA-x96j-244m-mrr2

rabbitmq-server: RabbitMQ: Atom-table exhaustion via reply-to queue name decoding

rabbitmq rabbitmq-server
Open in ThreatlineRecord JSON
CVSS
7.1High
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)0.33%Chance of exploitation activity in the next 30 days, higher than 24% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed inNone listedNo source names a fixed version. Check the vendor advisory below
Published23 Sep 2026Updated 24 Sep 2026CVE List

What fixes it

No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.

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.

Text from CVE List

Affected versions 2

  • rabbitmq-serveraffected: >= 4.2.0, < 4.2.7CVE List
  • rabbitmq-serveraffected: >= 4.3.0, < 4.3.1CVE List

References 3