Two critical access control vulnerabilities discovered in the RabbitMQ message broker could expose OAuth client secrets to unauthenticated attackers and allow authenticated users to bypass tenant boundaries, potentially leaking sensitive data across enterprise environments. Researchers from Miggo identified the flaws, which affect RabbitMQ release lines from version 3.13.0 onward and have been present in the codebase since early 2024. The first vulnerability, designated CVE-2026-57219, carries a CVSS score of 8.7 and involves an obsolete HTTP API endpoint that leaks the broker’s OAuth client secret. The second, CVE-2026-57221, is a missing authorization flaw rated 5.3 that permits any authenticated user to enumerate queues and exchanges in a virtual host and read message counts, irrespective of their assigned permissions. RabbitMQ maintainers have addressed both issues in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, with no evidence of active exploitation reported prior to public disclosure.
CVE-2026-57219: Unauthenticated Leak of OAuth Client Secrets
The more severe of the two vulnerabilities, CVE-2026-57219, resides in a legacy HTTP API endpoint at “GET /api/auth.” This endpoint, intended for older authentication workflows, was found to have a hard-coded authorization check that always permits the request. In RabbitMQ installations configured with OAuth 2 and the management.oauth_client_secret parameter, an unauthenticated attacker can retrieve the client secret in a single request. Once in possession of the secret, an attacker can exchange it for an administrator-level token, granting full control over every message, queue, user, and broker setting within the environment. Miggo’s analysis emphasizes that the risk is most acute in architectures where the management port is accessible from an untrusted network, such as cloud-based deployments, multi-tenant platforms, or any instance where the management UI is inadvertently exposed to the internet. The endpoint’s authorization bypass violates the security principle applied to all other sensitive management interfaces, making it a direct path to full broker takeover in configurations that rely on the exposed secret.
CVE-2026-57221: Cross-Tenant Data Enumeration by Authenticated Users
The second vulnerability, CVE-2026-57221, involves a missing authorization check that permits any authenticated user capable of connecting to a virtual host to enumerate all queue and exchange names within that host. The flaw also grants access to message count data and consumer count metrics, regardless of the user’s actual permissions. This effectively breaks tenant isolation in multi-tenant RabbitMQ deployments, where virtual hosts are used to segregate data between different customers or business units. An attacker with low-level authenticated access to one tenant can silently discover the messaging infrastructure of another tenant hosted on the same broker. While the CVSS score of 5.3 categorizes this as a medium-severity issue, the practical implications for data confidentiality in shared messaging environments are significant, as the exposed metadata could reveal application traffic patterns, business logic, and volume of sensitive transactions.
Additional Critical Flaws Patched in the Same Advisory Cycle
Alongside the two vulnerabilities disclosed by Miggo, RabbitMQ maintainers have also addressed a pair of critical-severity flaws that further underscore the importance of prompt patching. A TLS client-authentication bypass, assigned CVE-2026-57219, carries a CVSS score of 9.1 and could allow an attacker to circumvent mutual TLS authentication mechanisms. The second critical issue, scored at 9.2, enables an adversary in an adversary-in-the-middle (AitM) position to forge JSON Web Key Set (JWKS) responses, causing the broker to accept arbitrary JSON Web Tokens (JWTs). These vulnerabilities, combined with the access control flaws, present a comprehensive threat to RabbitMQ deployments, particularly those handling cross-tenant data or relying on OAuth-based authentication.
What Affected Organizations Should Do Now
Organizations running RabbitMQ versions 3.13.0 through 3.13.14, 4.0.0 through 4.0.19, 4.1.0 through 4.1.10, 4.2.0 through 4.2.5, or any pre-4.3.0 release should immediately upgrade to one of the patched versions. For installations where the management interface is accessible over the internet, the OAuth client secret should be rotated after patching to invalidate any potentially compromised tokens. As a compensating control, administrators should restrict network access to the management port (15672) to trusted internal networks only, preventing exposure to untrusted external traffic. In multi-tenant environments, tenant isolation should be reviewed and enforced at the virtual host level, and firewall rules should be implemented to block access to the vulnerable “/api/auth” endpoint on unpatched instances until the upgrade can be completed.
