RabbitMQ OAuth Secret Disclosure: Why Message Brokers Need Governed Data Paths

Abstract illustration of governed data pathways and controlled flow

When a message broker’s management endpoint discloses its own OAuth client secret, the broker’s identity plane turns into the attacker’s direct route to every queue, exchange, user account, and configuration setting under its control.

On July 13, 2026, Miggo Security published research on two access-control flaws in RabbitMQ discovered through their VulnHunter system and validated with human review. The findings were coordinated with RabbitMQ maintainers, with Michael Klishin credited for the response. The disclosure covers CVE-2026-57219 (CVSS v4.0 8.7) and CVE-2026-57221 (CVSS v4.0 5.3). SecurityWeek and CSO Online carried the story the same week. Miggo’s full report walks through the attack paths and the conditions that trigger them.

What happened

CVE-2026-57219 allows an unauthenticated attacker who can reach the management port (commonly 15672) to retrieve the broker’s confidential OAuth client secret through the obsolete GET /api/auth endpoint. The root cause sits in two functions: is_authorized/2 is hard-coded to always return true for this path, and produce_auth_settings/2 copies the oauth_client_secret value directly into the JSON response. Once the attacker possesses the secret, they can exchange it at the configured identity provider for an administrative token and assume full control over messages, queues, users, virtual hosts, and broker configuration.

The attack sequence is straightforward once the management port is reachable. The attacker issues the unauthenticated GET, receives the secret in the JSON body, and immediately presents that secret to the identity provider in a standard OAuth client-credentials flow. The resulting token carries the broker’s own administrative scope. From that point the attacker can create or delete queues, publish or consume messages at will, enumerate and modify users and permissions, and alter virtual-host configuration without ever authenticating as a legitimate application or user.

The vulnerability affects RabbitMQ versions 3.13.0 and later when the management plugin is enabled and OAuth is configured with a confidential client secret. It does not affect deployments that use no OAuth secret at all or that run without the management plugin. Public clients and PKCE flows that never store a client secret are unaffected because there is nothing to leak.

CVE-2026-57221 lets any authenticated user, even one with zero explicit permissions, enumerate queues and exchanges and read operational statistics. The flaw is missing authorization checks on passive-declare operations inside the management API. The issue does not expose message contents or permit modification, yet it leaks metadata that is valuable in multi-tenant or shared virtual-host environments where operational visibility itself is a boundary concern. An attacker with a low-privilege account can map the topology of every vhost, identify high-value queues by name or message rate, and gather the intelligence needed for targeted follow-on activity without triggering permission errors.

Both issues were introduced when OAuth support expanded in early 2024 and were fixed in the coordinated releases 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. The patch removes the obsolete /api/auth endpoint entirely; OAuth settings now flow only through the authenticated bootstrap.js path. Common identity providers named in the disclosure include Auth0, Microsoft Entra ID, Keycloak, and UAA.

Miggo notes that RabbitMQ sees roughly fifteen million downloads per year and runs in approximately eight percent of containers according to industry census data. At the time of disclosure there was no evidence of in-the-wild exploitation of these specific flaws.

Why this matters

Message brokers exist to move data between producers and consumers under identity and policy controls. When the broker’s own management plane hands over the credential that proves the broker’s identity to the identity provider, the entire chain of custody collapses. The first CVE converts an authentication path into a full administrative takeover. The second CVE turns routine metadata queries into an enumeration surface that crosses tenant boundaries without requiring elevated privileges.

These are not isolated authentication bugs. They are custody failures on the paths that govern how messages themselves are addressed, authorized, and audited. In regulated environments the broker already sits inside the data-movement perimeter; when its management surface leaks the secret that stands for the broker at the IdP, every downstream queue inherits that loss of control. The broker no longer enforces who may publish or consume; the attacker does.

The metadata leak compounds the problem in shared environments. Even without message contents, an attacker who can list every queue and its message rates gains a precise map of data flows. That map reveals which applications talk to which services, which tenants carry the highest volume, and where sensitive processing pipelines are likely to sit. Operational intelligence of that granularity is exactly the kind of artifact that appears in forensic reports after a larger breach.

Architecture implications

The management plane and the data plane of a message broker must be treated with the same segmentation and credential discipline applied to any other governed transfer path. OAuth client secrets that represent the broker itself deserve the same rotation, scoping, and network-access controls as the secrets that protect individual applications. Multi-tenant metadata leaks, even when they do not touch payload contents, still constitute a boundary violation that regulators and auditors will examine under the same lens used for document or object-store exfiltration.

The pattern echoes the third-party integration risks discussed in the Klue OAuth breach analysis and the RMM credential paths covered in the SimpleHelp disclosure: once an identity artifact that stands for the platform is disclosed, the attacker inherits the platform’s reach rather than a single user’s permissions. Message brokers simply make that inheritance more consequential because the platform in question is the one that routes every message in the system.

Practical takeaways

After applying the patch, rotate the RabbitMQ OAuth client secret. Assume the previous value is known to any party that reached the management endpoint before remediation.
Keep the management UI and API off untrusted networks. Segment it behind the same controls used for other privileged infrastructure surfaces.
Prefer OAuth grant types that do not rely on long-lived client secrets when the deployment model allows it. Public clients and short-lived tokens reduce the blast radius if a similar endpoint ever reappears.
Audit existing RabbitMQ instances for the combination of management plugin plus confidential OAuth client secret, and confirm that only the patched versions are reachable from the networks that can reach the management port.

Questions worth asking this week

Which RabbitMQ clusters in production use OAuth with a confidential client secret, and is the management plugin exposed beyond the trusted management network?
Do our logging and monitoring capture passive-declare operations and /api/auth requests so that enumeration or secret-fetch attempts would surface as anomalies?
If an attacker obtained a broker token through this path, what queues and exchanges would they be able to address, and do those paths carry regulated or customer data?
Are RabbitMQ management endpoints included in the same network segmentation reviews applied to other identity-bearing services such as internal IdPs or secrets managers?
After the coordinated patch rollout, has every affected instance had its OAuth client secret rotated and its management surface re-validated against the updated code?

Closing thought

RabbitMQ moves messages under identity-mediated policies. When the broker’s own secret leaks through its management surface, the identity that authorizes those messages becomes the attacker’s property. Message brokers are data-movement infrastructure; their management paths and broker-level credentials deserve the same governed-path treatment applied to every other route that carries regulated content.