CVE-2026-67235: RabbitMQ Memory Exhaustion DoS Vulnerability

CVE-2026-67235 Overview

CVE-2026-67235 is a resource exhaustion vulnerability in RabbitMQ, an open-source messaging and streaming broker. The flaw exists in how the broker handles the AMQP 0-9-1 content-header BodySize field. RabbitMQ stores this uint64 value without validating it against the configured max_message_size before assembly begins. An authenticated client with publish permission can declare body_size = 2^63-1 and stream fragments indefinitely, causing the reader process to accumulate memory without bound. The broker's memory alarm provides only reactive mitigation, degrading all publishers cluster-wide once triggered [CWE-770].

Critical Impact
Any authenticated AMQP 0-9-1 client with publish permission can exhaust node memory, degrading or halting message publishing across the entire cluster.

Affected Products

RabbitMQ Server versions prior to 3.13.15
RabbitMQ Server versions prior to 4.0.20, 4.1.11, and 4.2.6
RabbitMQ Server versions prior to 4.3.0

Discovery Timeline

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

Technical Details for CVE-2026-67235

Vulnerability Analysis

RabbitMQ implements AMQP 0-9-1 message framing using a content-header frame followed by one or more body frames. The content-header advertises the total message size via a 64-bit unsigned integer named BodySize. The broker's check_msg_size function enforces the max_message_size limit, but only after full message assembly completes. This ordering allows an attacker to bypass the size ceiling entirely by never letting assembly finish within a bounded window.

The reader process on the node receiving the fragmented publish accumulates buffers as body frames arrive. Because BodySize is trusted at declaration time and no incremental check compares accumulated bytes against max_message_size, memory usage grows unbounded. When the memory alarm eventually fires, RabbitMQ blocks all publishers cluster-wide as a protective measure, which itself constitutes a denial of service condition.

Root Cause

The root cause is missing input validation on the BodySize field of the content-header frame [CWE-770: Allocation of Resources Without Limits or Throttling]. The value is accepted as declared and used to control buffer growth without a preventive comparison against operator-configured limits.

Attack Vector

Exploitation requires network access to the AMQP 0-9-1 listener and valid credentials with publish permission on any exchange. The attacker opens a channel, sends a Basic.Publish method, follows with a content-header frame declaring BodySize = 0x7FFFFFFFFFFFFFFF, and then streams body frames without completing the message. The reader process retains all received fragments in memory until either the memory high-watermark alarm fires or the Erlang VM exhausts host memory and the node crashes.

Because AMQP 0-9-1 is RabbitMQ's most widely deployed protocol, any low-privilege user account is sufficient to trigger the condition. The impact propagates cluster-wide once flow control or the memory alarm engages.

Detection Methods for CVE-2026-67235

Indicators of Compromise

Sustained growth of the reader process memory footprint on a single connection, visible in rabbitmq_management or rabbitmqctl list_connections.
Frequent memory alarm activations logged in the RabbitMQ node log without a corresponding legitimate publish workload.
Long-lived channels where declared content-header BodySize values approach 2^63-1 or greatly exceed max_message_size.
Cluster-wide publisher flow control or blocked publisher notifications appearing shortly after a new connection is established.

Detection Strategies

Enable and monitor RabbitMQ's connection.blocked and memory alarm events through the management HTTP API or the firehose tracer.
Correlate authentication events with per-connection memory consumption to identify accounts driving abnormal reader-process growth.
Instrument network telemetry to flag AMQP sessions with unusually large declared content-header sizes relative to actual delivered payloads.

Monitoring Recommendations

Track the rabbitmq_process_memory_bytes and rabbitmq_connection_incoming_bytes_total metrics via Prometheus, alerting when a single connection's memory growth outpaces its committed message throughput.
Log all users with configure and write permissions and review publish-rate baselines to detect anomalous single-session pressure.
Forward RabbitMQ logs to a centralized analytics platform to correlate memory alarms with the originating connection, user, and client IP.

How to Mitigate CVE-2026-67235

Immediate Actions Required

Upgrade RabbitMQ to a fixed version: 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0.
Audit AMQP 0-9-1 user accounts and revoke publish permissions from any account that does not require them.
Restrict network exposure of AMQP listeners so only trusted application tiers can reach TCP port 5672.
Configure a conservative max_message_size and validate that operational monitoring captures per-connection memory growth.

Patch Information

The RabbitMQ maintainers fixed the issue by validating BodySize against max_message_size at content-header parse time, before body frames are accumulated. Fixed releases are documented in the GitHub Security Advisory GHSA-q8g2-pc7m-m3jw, the RabbitMQ 4.2.6 release notes, and the RabbitMQ 4.3.0 release notes.

Workarounds

Lower the vm_memory_high_watermark to force earlier alarm activation, reducing the blast radius while patching is scheduled.
Set an aggressive max_message_size value in rabbitmq.conf so that abusive publishers are terminated faster after the alarm engages.
Enforce per-user connection and channel limits via rabbitmqctl set_user_limits to reduce the number of concurrent abusive sessions a single account can open.
Isolate untrusted publishers behind a dedicated vhost with tightly scoped permissions and separate resource monitoring.

bash

# Configuration example: rabbitmq.conf
max_message_size = 16777216
vm_memory_high_watermark.relative = 0.4

# Apply per-user limits to constrain a single account's exposure
rabbitmqctl set_user_limits <username> '{"max-connections": 10, "max-channels": 20}'