CVE-2026-66080: RabbitMQ Stream Management DoS Vulnerability

CVE-2026-66080 Overview

CVE-2026-66080 is a resource exhaustion vulnerability in RabbitMQ, an open-source messaging and streaming broker. The flaw resides in the validate_partitions function used by the rabbitmq_stream_management plugin. The function validates that a requested partition count is at least 1 but enforces no upper bound. An authenticated caller with the management tag and access to the target vhost can request an extremely large partition count, forcing the broker to allocate approximately 8GB of memory for a request such as lists:seq(0, 500000000). The issue affects RabbitMQ versions prior to 4.1.11, 4.2.6, and 4.3.0.

Critical Impact
An authenticated user with management access can exhaust broker memory through a single crafted stream partition request, degrading availability for all connected producers and consumers.

Affected Products

RabbitMQ Server versions prior to 4.1.11
RabbitMQ Server versions prior to 4.2.6
RabbitMQ Server versions prior to 4.3.0 (with the rabbitmq_stream_management plugin enabled)

Discovery Timeline

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

Technical Details for CVE-2026-66080

Vulnerability Analysis

The vulnerability is classified under [CWE-770: Allocation of Resources Without Limits or Throttling]. The validate_partitions function in the rabbitmq_stream_management plugin performs only a lower-bound check, ensuring the requested partition count is greater than or equal to 1. It does not enforce an upper bound consistent with realistic streaming workloads.

When the broker processes a stream creation request that specifies a very large partition count, it generates a sequence list to represent the partitions. A request expressed in Erlang as lists:seq(0, 500000000) produces a list of 500 million integers, consuming roughly 8GB of resident memory on the broker node. Repeated or concurrent invocations can drive the node into memory pressure, trigger flow control, or terminate the Erlang VM.

Exploitation requires an authenticated principal, which limits the population of possible attackers. However, in shared-tenant or multi-team RabbitMQ deployments, any user granted the management tag on any vhost can trigger the condition.

Root Cause

The root cause is missing input validation in validate_partitions. The function accepts any integer greater than or equal to 1 without capping the value against server capacity or a sane operational maximum. Downstream code allocates memory proportional to the requested count without incremental checks.

Attack Vector

The attack vector is network-based against the RabbitMQ management HTTP API. Preconditions are:

The rabbitmq_stream_management plugin must be enabled on the broker.
The caller must hold the management tag.
The caller must have access to the target vhost.

An authenticated attacker submits a stream creation request specifying a partition count in the hundreds of millions. The broker attempts to allocate the corresponding data structure, exhausting available memory on the node.

No verified public exploit code has been published. Refer to the GitHub Security Advisory GHSA-wg79-5449-m728 for the vendor's technical description.

Detection Methods for CVE-2026-66080

Indicators of Compromise

Sudden growth in RabbitMQ node memory usage correlated with management API calls to stream creation endpoints.
Erlang VM crashes, node restarts, or memory_high_watermark alarms triggered shortly after a stream partition request.
Management API access logs showing stream creation requests with unusually large partitions parameter values.

Detection Strategies

Inspect RabbitMQ HTTP management logs for POST or PUT requests to stream endpoints containing large numeric partition values.
Alert on any RabbitMQ node whose resident memory grows by multiple gigabytes within seconds of an authenticated management API call.
Correlate authenticated management API activity with broker availability events to identify users triggering resource exhaustion.

Monitoring Recommendations

Track the rabbitmq_resident_memory_limit_bytes and erlang_vm_memory_bytes_total Prometheus metrics for anomalies.
Enable audit logging on management API operations, especially stream and queue creation actions.
Monitor which user accounts hold the management tag and review their vhost permissions regularly.

How to Mitigate CVE-2026-66080

Immediate Actions Required

Upgrade RabbitMQ Server to version 4.1.11, 4.2.6, or 4.3.0 or later as appropriate for your release train.
If upgrading is not immediately possible, disable the rabbitmq_stream_management plugin on brokers where stream management is not required.
Audit accounts with the management tag and remove access from principals that do not need it.

Patch Information

The RabbitMQ maintainers fixed the vulnerability in versions 4.1.11, 4.2.6, and 4.3.0. Details are available in the RabbitMQ Server Release v4.2.6 and RabbitMQ Server Release v4.3.0 release notes.

Workarounds

Disable the rabbitmq_stream_management plugin with rabbitmq-plugins disable rabbitmq_stream_management where stream management is not needed.
Restrict the management tag to a minimal set of trusted operators and enforce least privilege on vhost permissions.
Place the RabbitMQ management HTTP interface behind an authenticated reverse proxy with request-body inspection to reject requests containing implausibly large partition values.

bash

# Disable the vulnerable plugin if stream management is not required
rabbitmq-plugins disable rabbitmq_stream_management

# Verify the plugin is no longer enabled
rabbitmq-plugins list -e | grep stream_management

# Review users holding the management tag
rabbitmqctl list_users | grep management