CVE-2026-67238: RabbitMQ DOS Vulnerability

CVE-2026-67238 Overview

CVE-2026-67238 is a resource exhaustion vulnerability in RabbitMQ, an open-source messaging and streaming broker. The flaw resides in rabbit_pid_codec:decompose_from_binary/1, which parses caller-supplied Erlang External Term Format (ETF) binaries and calls binary_to_atom(Node, utf8) on the node-name field. Because Erlang atoms are never garbage collected, an authenticated Advanced Message Queuing Protocol (AMQP) client can exhaust the atom table with approximately 1 million cheap requests. The result is a crash of the entire Erlang virtual machine, taking down all virtual hosts and connections on the broker. RabbitMQ versions prior to 4.2.7 and 4.3.1 are affected [CWE-400].

Critical Impact
Any authenticated AMQP 0-9-1 client can crash the entire RabbitMQ Erlang VM, disrupting every vhost and connection served by the broker.

Affected Products

RabbitMQ Server versions prior to 4.2.7
RabbitMQ Server versions prior to 4.3.1
Deployments accepting authenticated AMQP 0-9-1 connections without aggressive per-connection rate limits

Discovery Timeline

2026-09-23 - CVE-2026-67238 published to the National Vulnerability Database
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-67238

Vulnerability Analysis

The vulnerability sits in RabbitMQ's process identifier (PID) codec. The function rabbit_pid_codec:decompose_from_binary/1 accepts an ETF-encoded binary from the caller and decodes its node-name field with binary_to_atom(Node, utf8). This code path is reachable through rabbit_volatile_queue:pid_from_name/2, which is invoked for any queue name or routing key beginning with amq.rabbitmq.reply-to..

Erlang enforces a fixed maximum atom table size, and atoms are never reclaimed by the garbage collector. Each unique node name supplied by an attacker consumes a permanent slot. Once the table fills, the Erlang VM terminates, taking the broker with it. Because the reply-to pseudo-queue path is exposed to any authenticated user, exploitation requires only a valid AMQP account.

Root Cause

The root cause is the use of binary_to_atom/2 on attacker-controlled input instead of binary_to_existing_atom/2. The candidate node membership check occurs after atom creation, so the atom is already interned before validation. The surrounding try/catch cannot release atoms that have been created, allowing unbounded growth of the atom table.

Attack Vector

An authenticated AMQP 0-9-1 client publishes or declares queues whose names begin with amq.rabbitmq.reply-to. and embed crafted ETF binaries with unique node-name fields. Repeated requests, on the order of one million, exhaust the atom table and crash the Erlang VM. No elevated privileges or user interaction are required beyond a valid connection to any vhost.

The vulnerability is described in prose because no verified proof-of-concept has been published. Refer to the GitHub Security Advisory GHSA-x96j-244m-mrr2 for further technical detail.

Detection Methods for CVE-2026-67238

Indicators of Compromise

Sudden growth in the Erlang atom table count reported by erlang:system_info(atom_count) on RabbitMQ nodes.
High volumes of AMQP operations referencing routing keys or queue names beginning with amq.rabbitmq.reply-to. from a single authenticated principal.
Unexpected Erlang VM crashes with system_limit errors related to atom table exhaustion in RabbitMQ logs.

Detection Strategies

Monitor RabbitMQ management metrics for anomalous per-user publish or declare rates against reply-to pseudo-queues.
Alert when atom_count approaches the configured +t atom table limit on any broker node.
Correlate authenticated AMQP session activity with broker crash events to identify the offending credential.

Monitoring Recommendations

Ingest RabbitMQ broker logs and Erlang crash dumps into a centralized logging platform for retention and analysis.
Track connection-level throughput and queue-declaration counts per user and per vhost.
Configure Prometheus exporters for RabbitMQ to expose erlang_vm_atom_count and alert on rate-of-change thresholds.

How to Mitigate CVE-2026-67238

Immediate Actions Required

Upgrade RabbitMQ to version 4.2.7 or 4.3.1, which replace the unsafe atom creation with binary_to_existing_atom.
Enforce strict per-connection and per-user rate limits on all AMQP clients until patching is complete.
Audit AMQP credentials and revoke unused or over-privileged accounts that can reach any vhost.

Patch Information

The RabbitMQ maintainers fixed CVE-2026-67238 in RabbitMQ Server 4.2.7 and 4.3.1. See the GitHub Release v4.2.7 and GitHub Release v4.3.1 notes for upgrade guidance.

Workarounds

Apply aggressive channel_max, frame_max, and per-connection message rate limits via broker policies to make ~1M operations infeasible.
Restrict AMQP network exposure to trusted client networks using firewalls or service-mesh policies.
Remove or restrict authenticated user permissions that allow declaring or consuming from amq.rabbitmq.reply-to.* pseudo-queues where feasible.

bash

# Configuration example: apply a restrictive rate limit policy
rabbitmqctl set_policy rate-limit "^amq\.rabbitmq\.reply-to\..*" \
  '{"max-length":1000,"overflow":"reject-publish"}' \
  --priority 10 --apply-to queues