CVE-2026-57219 can “leak the broker's confidential OAuth secret to an unauthenticated attacker in a single request,” researchers from Miggo warned, a failure they say creates a direct path to full broker takeover in some configurations.
Miggo researchers' disclosure and scope
Miggo's security team disclosed two access-control flaws in the RabbitMQ message broker that together threaten OAuth client secrets, cross-tenant isolation, and administrative control of messaging infrastructure. Both issues, the researchers say, lived in the RabbitMQ codebase since early 2024 and affect release lines from 3.13.0 and later. The flaws were fixed in releases 4.3.0, 4.2.6, 4.1.11, 4.0.20 and 3.13.15. Miggo reported no evidence of active exploitation prior to the public disclosure.
CVE-2026-57219: an obsolete endpoint that exposes an OAuth client secret
Miggo characterizes CVE-2026-57219 (CVSS score: 8.7) as a critical access-control error in an obsolete HTTP API endpoint. The vulnerable call — the "GET /api/auth" endpoint — can return the broker's OAuth client secret on RabbitMQ installations that used OAuth 2 and the management.oauth_client_secret configuration key. With that secret, an attacker can exchange it for an administrator token, and thus obtain “full control of every message, queue, user, and broker setting,” the researchers said.
Miggo also noted a coding error: “The endpoint's authorization check was hard-coded to always allow the request, unlike every other sensitive management endpoint.” The risk is highest where the RabbitMQ management port is reachable by untrusted networks — for example, cloud or multi-tenant deployments or a management UI accidentally exposed to the internet.
CVE-2026-57221: cross-tenant metadata exposure via missing authorization
The second flaw, CVE-2026-57221 (CVSS score: 5.3), stems from a missing authorization check. Any authenticated user who can connect to a virtual host can enumerate all queue and exchange names within that virtual host and read queue message counts and consumer counts — regardless of that user's intended permissions. In short, the vulnerability allows a logged-in user to silently read other tenants' queue and exchange metadata, undermining tenant separation and inventory confidentiality.
Affected versions, related fixes, and recommended mitigations
- Versions affected: RabbitMQ release lines from 3.13.0 and later; fixes are available in 4.3.0, 4.2.6, 4.1.11, 4.0.20 and 3.13.15.
- Immediate recommendations cited by Miggo and the advisory: patch to the fixed versions; rotate the OAuth client secret if the management interface was reachable over the internet; limit access to port 15672 to keep the management interface off untrusted networks; separate tenants by virtual host; and implement firewall rules to block the vulnerable endpoint on any unpatched instances.
- RabbitMQ maintainers also addressed two other high-severity issues in the same timeframe: a TLS client-authentication bypass (CVSS score: 9.1) and a vulnerability that could allow an adversary-in-the-middle to forge JWKS responses and cause the broker to accept arbitrary JWTs (CVSS score: 9.2).
What this means for cloud and multi-tenant operators, security teams, and adversaries
- Cloud and multi-tenant operators: The combination of an exposed OAuth secret and the ability for authenticated users to enumerate tenant metadata elevates the operational risk of shared or poorly segmented management planes. Operators will need to prioritize patching, ensure management ports like 15672 are not publicly reachable, and verify virtual-host separation is enforced.
- Security teams and administrators: Teams should treat any instance that used management.oauth_client_secret as compromised until the secret is rotated, patch systems to the specified fixed versions, and apply network-level controls and firewall rules recommended in the advisory.
- Adversaries and threat actors: Although Miggo reported no evidence of exploitation before disclosure, the technical path is clear: a single unauthenticated request can yield an OAuth secret in some configurations, and authenticated users can enumerate queue metadata. That combination presents distinct opportunities for reconnaissance and takeover if left unpatched.
Two straightforward facts anchor the risk: the flawed code existed since early 2024 in release lines still in use, and the fixes are available now. The public record shows no signs of past exploitation, but the mechanics — a hard-coded allow on a sensitive endpoint and a missing authorization check — remove significant barriers to abuse. Administrators who cannot immediately upgrade should assume exposure for any management port reachable from untrusted networks, rotate secrets tied to management.oauth_client_secret, and block the vulnerable endpoint at the network edge.
