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, 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.
CVE-2026-67238
Primary source · Revision 2
Imported from structured advisory data. Source references identify upstream records or fields; verify affected versions and your deployed configuration.
Security context
Source reference: cve:CVE-2026-67238
rabbitmq-server
Source reference: /containers/cna/affected/0/product
- Affected versions
- Not stated in this record
- Fixed versions
- Not stated in this record
- Prerequisites
- Not stated in this record
Structured affected-version data
Original package identities and version rules from this source.
[
{
"vendor": "rabbitmq",
"product": "rabbitmq-server",
"versions": [
{
"status": "affected",
"version": ">= 4.2.0, < 4.2.7"
},
{
"status": "affected",
"version": ">= 4.3.0, < 4.3.1"
}
]
}
]- Related CVEs
- CVE-2026-67238
Source reference:
/cveMetadata/cveId
Publisher severity
high
Source reference: /containers/cna/metrics
- Event
- #59636 · Revision 2
- Added to Heist Feed
- Publisher date