Miggo: RabbitMQ leaked OAuth secret via obsolete endpoint

Miggo’s security team disclosed two flaws in RabbitMQ today, and the first one reads less like a vulnerability report and more like a receipt. An obsolete HTTP API endpoint — kept around for backward compatibility, the way these things usually are — has been quietly returning the broker’s OAuth 2 client secret to any authenticated caller for roughly two years.

The endpoint is GET /api/auth. Per RabbitMQ’s security advisory, the bug affects installations that load the management plugin and configure OAuth 2 with management.oauth_client_secret — not the default posture, but a common enterprise one. Where it applies, an unauthenticated caller can hit that endpoint, receive the client secret back, and exchange it for an administrator token. The broker treats the token as legitimate because, structurally, it is.

Tracked as CVE-2026-57219, NVD scores it CVSS 7.5 (high), published 2026-07-10.

The second flaw is quieter but interesting for a different reason. CVE-2026-57221 — CVSS 5.0 (medium) per NVD, covered in advisory GHSA-9q2j-2hq8-22r2 — is a missing authorization check in the management API. An authenticated user can enumerate the names of every queue and exchange inside a virtual host, plus read their message and consumer counts, regardless of whether that user has been granted any actual permissions on those objects. Miggo characterizes it as a cross-tenant boundary bypass, which is fair whenever RabbitMQ vhosts are being used as the isolation layer between SaaS tenants — as they routinely are.

Affected versions and fixes

Both flaws affect broker releases 3.13.0 and later. The fixed versions, per the advisories:

• 4.3.0
• 4.2.6
• 4.1.11
• 4.0.20
• 3.13.15

Miggo reports CVE-2026-57219 has been present in the codebase since early 2024. Neither the researcher nor RabbitMQ has observed exploitation in the wild ahead of disclosure.

What operators should do

Patch to one of the fixed lines above. If patching has to wait, the interim controls are the ones you’d expect: keep the management API off the public network, avoid running OAuth 2 with management.oauth_client_secret unless the deployment truly requires it, and audit recently-issued administrator tokens for anything you don’t recognize. The vendor advisories cover the mitigation surface in detail; they should be the reference, not a summary of them.

The lesson underneath the CVE numbers

Obsolete endpoints don’t disappear on their own. Someone has to remove them, and until someone does they sit there quietly returning whatever they were built to return in whatever year they were written. GET /api/auth was replaced years ago. The replacement did not delete the original. The original kept working, kept being reachable, and kept being what it had always been: a plaintext handoff of a client secret to whoever asked.

The multi-tenant enumeration is the same shape at a different layer. RabbitMQ vhosts were designed as a routing and namespace primitive; the industry started using them as tenant isolation, and the authorization checks in the management API never quite caught up. That gap is not novel — the same pattern has surfaced in Writer AI’s session sandbox earlier this month, and in CISA’s own dormant GitHub metadata last week. Neither is a RabbitMQ problem; both are a problem RabbitMQ has now inherited by being the thing enterprises reach for when they need a shared broker across tenants.

Patch, then take the harder look at what else in your stack was designed for a smaller world than the one it’s running in.