CVE-2026-66070: RabbitMQ Management Plugin CSRF Vulnerability

CVE-2026-66070 Overview

CVE-2026-66070 affects the RabbitMQ management plugin's Cross-Origin Resource Sharing (CORS) handler. When operators configure the wildcard origin cors_allow_origins = "*", the match_origin/1 function in rabbit_mgmt_cors.erl reflects the attacker-supplied Origin header back in Access-Control-Allow-Origin while also emitting Access-Control-Allow-Credentials: true. This combination allows a malicious web page visited by a signed-in administrator to issue authenticated, state-changing requests to the RabbitMQ management API using cached HTTP Basic credentials. The issue is fixed in RabbitMQ versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6.

Critical Impact
An attacker-controlled site can perform authenticated management API operations as any administrator whose browser holds a cached Basic-auth session against a wildcard-CORS RabbitMQ node.

Affected Products

RabbitMQ Server versions prior to 3.13.17
RabbitMQ Server 4.0.x prior to 4.0.22, and 4.1.x prior to 4.1.13
RabbitMQ Server 4.2.x prior to 4.2.6

Discovery Timeline

2026-09-23 - CVE-2026-66070 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-66070

Vulnerability Analysis

The flaw sits in rabbit_mgmt_cors.erl, the module that generates CORS response headers for the management HTTP API. When the operator sets cors_allow_origins = "*", the match_origin/1 helper returns the bare reflected Origin value from the incoming request rather than the literal wildcard. RabbitMQ then attaches Access-Control-Allow-Credentials: true to the same response.

Modern browsers reject the combination of a literal * and credentials, but they accept a reflected origin paired with credentials. That is precisely the response shape this handler produces. The result is a CORS misconfiguration classified under [CWE-942: Permissive Cross-domain Policy with Untrusted Domains].

The vulnerability is a permissive cross-domain policy issue, not a memory-safety bug. It converts a common operator misconfiguration into a browser-driven cross-origin authenticated request path against the management API.

Root Cause

The root cause is incorrect wildcard handling in match_origin/1. Instead of returning the literal * (which browsers refuse to combine with credentials), the function echoes the request's Origin header. The handler then unconditionally adds Access-Control-Allow-Credentials: true, defeating the browser protection that wildcard CORS is supposed to provide.

Attack Vector

Exploitation requires two preconditions. First, the operator must have configured the management plugin with cors_allow_origins = "*". Second, a target administrator must have a cached HTTP Basic-auth session for the management UI in the same browser.

The attacker lures the administrator to a malicious page. That page issues fetch or XMLHttpRequest calls to the RabbitMQ management API with credentials: "include". Because the server echoes the attacker's origin and allows credentials, the browser attaches the cached Basic-auth header and delivers the response to attacker JavaScript. The attacker can create users, grant permissions, or modify queues and policies.

No verified exploit code is published for this issue. See the GitHub Security Advisory GHSA-p3hp-v9wh-ghm7 for vendor technical details.

Detection Methods for CVE-2026-66070

Indicators of Compromise

Management API access log entries showing state-changing requests (PUT, POST, DELETE on /api/users, /api/permissions, /api/policies) with a browser User-Agent and a non-console Referer or Origin header.
HTTP responses from the management endpoint that include both Access-Control-Allow-Credentials: true and a reflected, non-trusted Access-Control-Allow-Origin value.
Unexpected creation of administrator accounts, permission grants, or virtual host modifications correlated with an administrator's browser session.

Detection Strategies

Inspect the RabbitMQ configuration for cors_allow_origins = "*" across all nodes and environments.
Send an OPTIONS preflight to /api/overview with a synthetic Origin header and confirm the response no longer reflects arbitrary origins alongside credentials.
Correlate management API audit logs with browser-originated requests carrying Origin headers that do not match the operator's trusted UI hostnames.

Monitoring Recommendations

Enable and centralize RabbitMQ management HTTP access logs for retention and query.
Alert on any Access-Control-Allow-Origin response value that is neither a configured trusted origin nor absent.
Monitor administrative changes to users, permissions, and policies for out-of-band activity outside change windows.

How to Mitigate CVE-2026-66070

Immediate Actions Required

Upgrade RabbitMQ Server to 3.13.17, 4.0.22, 4.1.13, or 4.2.6 or later, matching your deployed branch.
Replace cors_allow_origins = "*" with an explicit allow-list of trusted origins until patched builds are deployed.
Rotate credentials for administrator accounts if wildcard CORS was previously enabled on an internet-reachable node.

Patch Information

The issue is fixed in RabbitMQ Server 3.13.17, 4.0.22, 4.1.13, and 4.2.6. See the RabbitMQ Server Release v4.2.6 notes and the GitHub Security Advisory GHSA-p3hp-v9wh-ghm7 for advisory details and commit references.

Workarounds

Remove the wildcard and enumerate trusted origins explicitly in cors_allow_origins.
Restrict management plugin exposure to management networks or VPN, and block direct browser access from untrusted networks.
Require administrators to sign out of the management UI after use to invalidate cached HTTP Basic sessions.

bash

# Configuration example: rabbitmq.conf
# Replace the wildcard with an explicit allow-list of trusted origins
management.cors.allow_origins.1 = https://rabbitmq-ui.internal.example.com
management.cors.allow_origins.2 = https://ops.example.com
# Do NOT use: cors_allow_origins = "*"