CVE-2026-66074: RabbitMQ Management API DoS Vulnerability

CVE-2026-66074 Overview

CVE-2026-66074 is a denial of service vulnerability in RabbitMQ, an open source messaging and streaming broker. The flaw exists in the match_value/3 function used by management API list endpoints. The function passes a user-supplied ?name= regular expression to Erlang's re:run without a match_limit option, then executes the regex once per resource in the result set. An authenticated user with the management tag can trigger sustained CPU exhaustion by combining the use_regex=true option with a large result set. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

Critical Impact
A single authenticated request can consume 12 or more minutes of CPU time, and parallel requests saturate the Erlang schedulers, degrading broker availability.

Affected Products

RabbitMQ versions prior to 3.13.15
RabbitMQ 4.0.x prior to 4.0.20, 4.1.x prior to 4.1.11, and 4.2.x prior to 4.2.6
RabbitMQ management plugin list endpoints supporting use_regex=true

Discovery Timeline

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

Technical Details for CVE-2026-66074

Vulnerability Analysis

The RabbitMQ management plugin exposes list endpoints for queues, exchanges, bindings, and other resources. These endpoints accept a name query parameter combined with use_regex=true to filter results by regular expression. Internally, the match_value/3 helper forwards the attacker-controlled pattern to Erlang's re:run with default options.

OTP's default match_limit of 10,000,000 caps a single re:run invocation at roughly 100 to 200 milliseconds on typical hardware. The regex is evaluated once per resource in the result set rather than once overall. With 5,000 queues at 150 ms each, one HTTP request consumes over twelve minutes of CPU time. Concurrent requests multiply the cost and saturate every Erlang scheduler, blocking legitimate broker operations.

The underlying weakness is inefficient regular expression complexity [CWE-1333], commonly known as ReDoS. Because use_regex=true is a documented feature, the vulnerable path is reachable through normal API traffic and does not require any protocol abuse.

Root Cause

The root cause is the absence of a bounded match_limit when invoking re:run, combined with per-resource iteration. The management API trusts user-supplied patterns without capping cumulative regex execution cost across the result set.

Attack Vector

Exploitation requires network access to the management HTTP API and an authenticated account carrying the management tag, which is the lowest-privilege role in the RabbitMQ management UI. An attacker sends a GET request to a list endpoint such as /api/queues with use_regex=true and a catastrophic-backtracking pattern in the name parameter. Repeating the request in parallel exhausts scheduler capacity.

See the GitHub Security Advisory GHSA-rg5q-vcgf-rfh7 for the vendor's technical description of the vulnerable code path.

Detection Methods for CVE-2026-66074

Indicators of Compromise

HTTP requests to management API list endpoints containing use_regex=true combined with unusually long or complex name patterns.
Sustained high CPU utilization on RabbitMQ nodes correlated with management API traffic from a single authenticated principal.
Erlang scheduler saturation and increasing request latency across unrelated broker operations.

Detection Strategies

Parse HTTP access logs from the management plugin and alert on use_regex=true requests where the name parameter exceeds a length or complexity threshold.
Baseline management API request duration per endpoint and flag requests that exceed the 95th percentile by an order of magnitude.
Correlate authenticated management-tag sessions with node CPU spikes to identify a single actor triggering scheduler exhaustion.

Monitoring Recommendations

Track erlang_vm_scheduler_utilization and per-node CPU metrics through the Prometheus plugin and alert on sustained saturation.
Monitor the count of concurrent management API requests per user and per source IP.
Review audit logs for accounts holding the management tag and validate that active credentials belong to expected operators or applications.

How to Mitigate CVE-2026-66074

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0, matching the release train currently in production.
Audit all accounts carrying the management tag and revoke access for identities that do not require the management UI or HTTP API.
Rotate credentials for any management-tagged account that may have been exposed to untrusted networks.

Patch Information

The vendor addressed the flaw by bounding re:run execution when processing management API filters. Patched builds are available in the RabbitMQ v4.2.6 Release Notes and the RabbitMQ v4.3.0 Release Notes. Backported fixes are included in 3.13.15, 4.0.20, and 4.1.11.

Workarounds

Restrict network access to the management HTTP API (default TCP port 15672) to trusted operator networks using a firewall or reverse proxy.
Place a reverse proxy in front of the management API that strips or rejects requests containing use_regex=true.
Enforce per-user rate limits on management API endpoints to cap the CPU cost a single principal can impose.

bash

# Configuration example: restrict management API and disable unused listeners
# /etc/rabbitmq/rabbitmq.conf
management.tcp.ip = 127.0.0.1
management.tcp.port = 15672

# Remove the management tag from application service accounts
rabbitmqctl set_user_tags app_service ""