CVE-2026-67238: CWE-400: Uncontrolled Resource Consumption in rabbitmq rabbitmq-server
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.
AI Analysis
Technical Summary
The vulnerability arises from the function rabbit_pid_codec:decompose_from_binary/1, which parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. This occurs in the context of rabbit_volatile_queue:pid_from_name/2 for queue names or routing keys beginning with amq.rabbitmq.reply-to. Because atoms are never garbage collected in Erlang and binary_to_existing_atom is not used, each request creates a new atom, leading to uncontrolled resource consumption. The CandidateNodes membership check happens after atom creation, so it does not prevent atom exhaustion. An authenticated AMQP 0-9-1 client without strict per-connection rate limits can crash the entire Erlang VM by sending about one million such requests. The vulnerability is addressed in rabbitmq-server versions 4.2.7 and 4.3.1.
Potential Impact
Exploitation allows any authenticated AMQP client to crash the entire Erlang VM hosting rabbitmq-server, resulting in denial of service affecting all virtual hosts and connections. This can disrupt messaging and streaming services relying on RabbitMQ.
Mitigation Recommendations
This vulnerability is fixed in rabbitmq-server versions 4.2.7 and 4.3.1. Users should upgrade to at least these versions to remediate the issue. No additional mitigation steps are indicated by the vendor advisory.
CVE-2026-67238: CWE-400: Uncontrolled Resource Consumption in rabbitmq rabbitmq-server
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.
CVSS v4.0
Score 7.1high
Affected software
rabbitmq
rabbitmq-server
pkg:github/rabbitmq/rabbitmq-serverRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises from the function rabbit_pid_codec:decompose_from_binary/1, which parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. This occurs in the context of rabbit_volatile_queue:pid_from_name/2 for queue names or routing keys beginning with amq.rabbitmq.reply-to. Because atoms are never garbage collected in Erlang and binary_to_existing_atom is not used, each request creates a new atom, leading to uncontrolled resource consumption. The CandidateNodes membership check happens after atom creation, so it does not prevent atom exhaustion. An authenticated AMQP 0-9-1 client without strict per-connection rate limits can crash the entire Erlang VM by sending about one million such requests. The vulnerability is addressed in rabbitmq-server versions 4.2.7 and 4.3.1.
Potential Impact
Exploitation allows any authenticated AMQP client to crash the entire Erlang VM hosting rabbitmq-server, resulting in denial of service affecting all virtual hosts and connections. This can disrupt messaging and streaming services relying on RabbitMQ.
Mitigation Recommendations
This vulnerability is fixed in rabbitmq-server versions 4.2.7 and 4.3.1. Users should upgrade to at least these versions to remediate the issue. No additional mitigation steps are indicated by the vendor advisory.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-07-28T19:50:39.438Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6ab43089f7a7c54106431427
Added to database: 09/23/2026, 20:03:21 UTC
Last enriched: 09/23/2026, 20:18:18 UTC
Last updated: 09/24/2026, 01:57:04 UTC
Views: 7
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.