CVE-2026-66070: RabbitMQ: CORS * reflects Origin with Allow-Credentials
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, matchorigin/1 returned the bare reflected Origin and allowed credentials even when the wildcard "" was configured, so the response echoed the attacker's origin together with Access-Control-Allow-Credentials. The affected code is rabbitmgmtcors.erl. When the management plugin is configured with a wildcard CORS origin (corsalloworigins = ""), the handler reflects the request Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. A malicious web page that a signed-in administrator visits can then use that administrator's cached HTTP Basic credentials to issue authenticated, state-changing requests to the management API. Preconditions include The management plugin is configured with the wildcard corsalloworigins = "", which is an explicit operator misconfiguration A target administrator has a cached HTTP Basic-auth session in the browser. This issue is fixed in versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.17 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.22 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.13 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6
Event History
Frequently Asked Questions
Which deployments are exposed?
Only RabbitMQ deployments with the management plugin enabled and explicitly configured with cors_allow_origins = "*" are affected. This is not described as a default configuration issue.
What does an attacker need to exploit this?
An attacker needs to induce a signed-in RabbitMQ administrator to visit a malicious web page. The administrator must have cached HTTP Basic-auth credentials in the browser, allowing the page to make authenticated state-changing management API requests.
What should operators do if they cannot upgrade immediately?
Remove the wildcard CORS setting and restrict cors_allow_origins to trusted origins rather than "*". This prevents arbitrary attacker-controlled origins from being reflected with credentialed CORS access.
How can I determine whether my instance is vulnerable?
Check the RabbitMQ management plugin configuration for cors_allow_origins = "*" and determine whether the deployment is older than 3.13.17, 4.0.22, 4.1.13, or 4.2.6 for its applicable release line. Affected behavior occurs in rabbit_mgmt_cors.erl when that wildcard setting is used.