CORS credential reflection in RabbitMQ management plugin enables admin session hijacking
AI analysis
RabbitMQ's management plugin CORS handler (rabbit_mgmt_cors.erl, match_origin/1) reflects any request Origin and sends Access-Control-Allow-Credentials: true even when the operator has configured the wildcard cors_allow_origins = "*". Because the Access-Control-Allow-Origin header echoes back the attacker's own origin, a malicious web page visited by an administrator can make authenticated, state-changing requests to the management API using that administrator's cached HTTP Basic-auth credentials. An attacker thereby gains the administrator's full management privileges over the broker (user, vhost, queue, and permission changes via the API) from an arbitrary website. Only deployments that explicitly set the wildcard CORS origin are exploitable, and the flaw is fixed in 3.13.17, 4.0.22, 4.1.13, and 4.2.6. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not in CISA's KEV catalog.
What to do: Upgrade to 3.13.17, 4.0.22, 4.1.13, or 4.2.6 depending on your release branch. Regardless of upgrade, remove cors_allow_origins = "*" from rabbitmq.conf and replace it with an explicit list of trusted origins — this eliminates the precondition entirely. Also restrict the management plugin port (15672) to trusted networks or VPN, and instruct administrators not to leave cached HTTP Basic credentials in shared or long-lived browser sessions.
Affected
| RabbitMQ (management plugin, rabbit_mgmt_cors.erl) | All versions prior to 3.13.17 (3.13.x branch) |
| RabbitMQ (management plugin, rabbit_mgmt_cors.erl) | All versions prior to 4.0.22 (4.0.x branch) |
| RabbitMQ (management plugin, rabbit_mgmt_cors.erl) | All versions prior to 4.1.13 (4.1.x branch) |
| RabbitMQ (management plugin, rabbit_mgmt_cors.erl) | All versions prior to 4.2.6 (4.2.x branch) |
Description
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, match_origin/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 rabbit_mgmt_cors.erl. When the management plugin is configured with a wildcard CORS origin (cors_allow_origins = ""), 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 cors_allow_origins = "*", 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.