CVE-2026-66070 in RabbitMQ
Summary
by MITRE • 09/23/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in RabbitMQ management plugin interfaces represents a critical misconfiguration flaw within the Cross-Origin Resource Sharing (CORS) implementation. Specifically, the function match_origin/1 located in the rabbit_mgmt_cors.erl module fails to properly validate or sanitize the Origin header when the system is configured with a wildcard CORS origin setting. In versions prior to 3.13.17, 4.0.22, 4.1.13, and 4.2.6, if an administrator configures cors_allow_origins to accept all origins using the wildcard character "*", the server incorrectly reflects the attacker's Origin header back in the Access-Control-Allow-Origin response field while simultaneously setting Access-Control-Allow-Credentials to true. This behavior violates standard CORS security models which dictate that when credentials are allowed, the origin must be explicitly listed rather than reflected from a wildcard configuration, thereby creating an opening for cross-origin attacks against authenticated sessions.
From a technical perspective, this flaw aligns with CWE-942, which describes Permissive Cross-domain Policy with Untrusted Domains, and specifically relates to improper validation of user-supplied input in the context of web security headers. The core issue lies in the server's decision to echo back the requesting origin when credentials are enabled under a wildcard policy. Normally, browsers enforce strict same-origin policies that prevent scripts from reading responses unless specific CORS headers permit it. By returning both Access-Control-Allow-Origin set to the attacker's domain and Access-Control-Allow-Credentials: true, RabbitMQ effectively tells the browser that requests originating from any arbitrary website are authorized to send credentials such as HTTP Basic authentication tokens or cookies. This creates a scenario where state-changing API endpoints become accessible to malicious third-party sites without triggering standard cross-origin restrictions.
The operational impact of this vulnerability is severe for organizations relying on RabbitMQ's management interface for cluster administration. An attacker can craft a malicious web page designed to exploit the browser's automatic inclusion of cached HTTP Basic credentials when making requests to the RabbitMQ API. If an administrator, who has previously authenticated via their browser and thus retains valid session cookies or basic auth tokens in memory, visits this malicious site, the embedded script within that site can initiate XMLHttpRequests or fetch calls against the RabbitMQ management plugin endpoints. Because of the flawed CORS response headers, the browser will allow these requests to proceed with full administrative privileges. This enables the attacker to perform arbitrary actions such as creating queues, deleting messages, changing user permissions, or shutting down nodes, effectively compromising the integrity and availability of the messaging infrastructure without needing explicit credentials beyond what is cached in the victim's browser session.
This attack vector closely mirrors techniques documented in MITRE ATT&CK framework under T1506, specifically using web cookies for persistence or privilege escalation through cross-site request forgery mechanisms facilitated by misconfigured CORS policies. The precondition for this exploit requires two specific conditions: first, the RabbitMQ management plugin must be explicitly configured with a wildcard cors_allow_origins setting, which is often done inadvertently during initial setup to simplify development testing but left active in production environments; second, the target administrator must have an active or cached authentication session within their web browser. The combination of these factors allows for unauthorized administrative access that bypasses traditional network-based security controls because the request appears legitimate from the perspective of the victim's own browser and identity context.
Mitigation strategies focus on correcting the CORS configuration to adhere to secure defaults recommended by industry standards such as OWASP Secure Headers Project. Administrators should immediately update RabbitMQ to version 3.13.17, 4.0.22, 4.1.13, or 4.2.6 where this logic has been corrected to prevent the reflection of origins when credentials are enabled under wildcard policies. In addition to upgrading, it is critical to review and restrict cors_allow_origins configurations in production environments. Instead of using wildcards, administrators should explicitly list only the trusted domains that require access to the management API. Furthermore, implementing Content-Security-Policy headers with strict directives regarding frame-ancestors can provide an additional layer of defense against clickjacking or script injection attacks that might attempt to leverage this CORS misconfiguration. Regular security audits of web application configurations are essential to ensure that development-oriented settings like wildcard CORS do not persist in production deployments, thereby maintaining the principle of least privilege and reducing the attack surface for cross-origin exploits.