CVE-2026-67238

Undergoing Analysis Undergoing Analysis - In Progress

Denial of Service in RabbitMQ via ETF Parsing

Publication date: 2026-09-23

Last updated on: 2026-09-24

Assigner: GitHub, Inc.

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 Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-23

Last Modified

2026-09-24

Generated

2026-10-14

AI Q&A

2026-09-24

EPSS Evaluated

2026-10-12

NVD

CVE-2026-67238

EUVD

EUVD-2026-85624

Affected Vendors & Products

Vendor	Product	Version / Range
rabbitmq	rabbitmq	to 4.3.1 (exc)
rabbitmq	rabbitmq	to 4.2.7 (exc)
rabbitmq	rabbitmq	4.2.7
rabbitmq	rabbitmq	4.3.1

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-400	The product does not properly control the allocation and maintenance of a limited resource.

Attack-Flow Graph

Executive Summary

This vulnerability in RabbitMQ versions 4.2.0 to 4.2.6 and 4.3.0 allows an authenticated AMQP client to crash the entire Erlang VM by exploiting atom table exhaustion. The issue occurs when parsing a caller-supplied ETF-encoded binary in the rabbit_pid_codec:decompose_from_binary/1 function, which calls binary_to_atom(Node, utf8) on a node-name field. This is triggered by queue names or routing keys starting with amq.rabbitmq.reply-to. The atom created is never garbage-collected, leading to permanent memory consumption. An attacker can craft a malicious PidBin value, base64-encode it, and send it either as a basic.publish with a specific routing key or as a queue.declare command.

Detection Guidance

Monitor for excessive atom table usage in the Erlang VM. Check for repeated crashes or system_limit errors in RabbitMQ logs. Use Erlang commands like 'erlang:memory(atom)' to inspect atom table size. Look for queue names or routing keys starting with 'amq.rabbitmq.reply-to.' in AMQP traffic.

Impact Analysis

This vulnerability can cause a denial of service (DoS) by crashing the entire Erlang VM, affecting all virtual hosts and connections. An attacker can exploit it with approximately 1 million cheap requests, leading to system unavailability. The impact includes permanent resource exhaustion due to atom table filling, requiring a restart of the RabbitMQ service.

Compliance Impact

This vulnerability primarily causes a denial of service (DoS) by exhausting system resources through atom table exhaustion, which can crash the entire Erlang VM. For compliance standards like GDPR and HIPAA, which require availability and integrity of data processing systems, this could lead to service disruptions, potential data loss, or unauthorized access during downtime. The inability to maintain system availability violates key requirements of these regulations.

Mitigation Strategies

Upgrade RabbitMQ to version 4.2.7 or 4.3.1 immediately. Apply per-connection rate limiting to prevent rapid requests. Restrict AMQP client authentication to trusted sources. Monitor for unusual queue declarations or routing key patterns.

Hi! I’m here to help you understand CVE-2026-67238. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70