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.
{
"cna_assigner": "GitHub_M",
"cwe_ids": [
"CWE-400"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/67xxx/CVE-2026-67238.json"
}{
"extracted_events": [
{
"range": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.7"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.1"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"original_tag": "v4.2.7",
"range": [
{
"fixed": "b15fd2a3e5465cb6ed403d5a774ef61b1a391b89"
}
],
"source": "REFERENCES_TAG"
},
{
"original_tag": "v4.3.1",
"range": [
{
"fixed": "49decca35e59d2cb774e5abd76412cee721308a5"
}
],
"source": "REFERENCES_TAG"
}
]
}