TL;DR
Miggo's security team discovered two critical access-control flaws in RabbitMQ: one that leaks the broker's confidential OAuth secret to an unauthenticated attacker in a single request, a direct path to full broker takeover in the configurations that use that secret, and one that lets any logged-in user silently read other tenants' data. Both are now patched.
Background on RabbitMQ
RabbitMQ is the most widely deployed open-source message broker in the world. It is the plumbing that moves data between services inside modern applications: orders, payments, authentication events, internal notifications. When your checkout flow confirms a purchase, when your auth service triggers an email, when your backend services talk to each other, RabbitMQ is likely in the middle of it.
The scale makes it a high-value target. RabbitMQ is downloaded more than 15 million times a year. By one industry census, 8% of all containers running anywhere on earth exist to run RabbitMQ. When a broker like this can be taken over, everything flowing through it becomes exposed.
The Findings at a Glance
Miggo's security team discovered two access-control vulnerabilities in RabbitMQ, both present in the codebase since early 2024 and both now patched by the RabbitMQ maintainers following coordinated disclosure.
CVE-2026-57219: OAuth client-secret disclosure to full broker takeover. High severity (CVSS v4.0 8.7). No authentication required. An open management endpoint returns the broker's confidential OAuth client secret to anyone who asks. Reading the secret takes one unauthenticated request. Where the configured OAuth grant uses that secret (the standard confidential-client setup for Auth0, Entra ID, Keycloak, and UAA), an attacker exchanges it for an administrator token and gains full control of every message, queue, user, and broker setting.
CVE-2026-57221: Passive-declare authorization bypass to tenant metadata leak. Moderate severity (CVSS v4.0 5.3, CWE-862 Missing Authorization). Requires only a valid login, even a zero-permission one. A routine "does this exist?" operation skips its permission check entirely, letting any authenticated user enumerate queues and exchanges and read their statistics, regardless of their actual permissions.
Both affect RabbitMQ release lines from 3.13.0 onward. Both are fixed in 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. There is no evidence either has been exploited in the wild.
Thank you, @michaelklishin, for the help in the disclosure and the mitigation of the two reported vulnerabilities.
The Wizard Behind the Miggo Curtain
Both vulnerabilities were discovered by Miggo's autonomous security research system, VulnHunter, which works through a target's codebase looking for exactly this kind of subtle, systemic inconsistency: an endpoint that authorizes differently from its peers, an operation that skips a check its siblings perform.
Rather than a single agent reading code top to bottom, VulnHunter fields a team of agents working a target in parallel, each owning a component, coordinating through shared state, and promoting only findings backed by both code evidence and runtime evidence. One disclosed run on RabbitMQ spanned roughly seven hours and 206 hypotheses. Both bugs it surfaced are "inconsistency" bugs: the kind that rewards broad, systematic, side-by-side coverage of a large application surface far more than a single deep dive into one file.
A member of Miggo's security team validated each finding and drove coordinated disclosure with the RabbitMQ maintainers, who confirmed both issues and shipped patches. These are the first CVEs at Miggo discovered by an autonomous agent rather than a human researcher.
Deep Dive into the CVEs
CVE-2026-57219: The Endpoint That Gave Away the Keys
Here is the counterintuitive part: the credential that was leaking was the server's own OAuth secret, handed to anyone who asked, by the very endpoint meant to secure logins, with no password required.
RabbitMQ's management web interface shipped an obsolete endpoint, GET /api/auth, that returned the server's OAuth 2 configuration to anyone who asked, no login required. When an operator had configured management.oauth_client_secret (the confidential password the broker uses to authenticate with its identity provider), that secret was included in the response. Anyone who could reach the management port could fetch it, then, where the OAuth grant makes the secret usable, impersonate the broker to the identity provider and obtain an administrator token.
The bug had been in the codebase since RabbitMQ 3.13.0, introduced in early 2024.
Why it happened
The endpoint's authorization check was hard-coded to always allow the request, unlike every other sensitive management endpoint. In the vulnerable source (deps/rabbitmq_management/src/rabbit_mgmt_wm_auth.erl), the is_authorized/2 callback simply returned {true, ...} unconditionally, and the response builder produce_auth_settings/2 copied oauth_client_secret straight into the JSON payload.
The attacker's path: from nothing to full control
- Attacker finds a RabbitMQ management interface reachable over the network (port 15672).
- Sends one unauthenticated request:
GET /api/auth. - The response contains the confidential
OAuth client_secret. - Attacker uses that secret to request an access token from the organization's identity provider.
- Attacker presents the token to RabbitMQ and is admitted with administrator privileges.
- Attacker now controls all messages, queues, users, and broker configuration.
The leaked value is a long-lived credential. A single GET is all it takes to obtain it. Patching removes the endpoint but does not invalidate a secret that may already be in an attacker's hands.
Who is exposed
Deployments that use OAuth 2 with management.oauth_client_secret and have the management plugin enabled. Operators who put RabbitMQ behind an OAuth 2/OIDC provider (Auth0, Azure AD/Entra ID, Keycloak, UAA) should treat themselves as in-scope. Deployments with no OAuth 2 are not affected. Setups that don't configure a client secret (for example a public client using PKCE, RabbitMQ's recommended management-UI configuration) have no secret to leak; and deployments monitoring only via Prometheus/Grafana (no management plugin) are not affected. The risk is sharpest wherever the management port is reachable by an untrusted network: cloud or multi-tenant setups, or a management UI accidentally exposed to the internet.
The fix (and the catch)
Upgrade to a patched release (4.3.0, 4.2.6, 4.1.11, 4.0.20, or 3.13.15). The fix removes the obsolete /api/auth endpoint entirely. OAuth settings now reach the UI through the authenticated bootstrap.js path instead, so the secret is never served over HTTP. If you can't patch immediately, disable the OAuth 2 plugin, switch to a grant type that doesn't use a client secret, or disable the management plugin and keep port 15672 off untrusted networks.
One thing patching alone won't undo: if the secret was exposed before you upgraded, it stays valid until you rotate it. Rotate the OAuth client secret after upgrading and assume it leaked. Frozen container images, pinned Helm charts, and RabbitMQ embedded inside other products all keep vulnerable versions alive long after the upstream fix.
If you can't patch right away, Miggo's WAF rule blocks all access to the vulnerable endpoint and protects unpatched instances. There are no variants of this attack, so the rule covers it completely.
CVE-2026-57221: The Check That Forgot to Check
What it is
The counterintuitive part here: a RabbitMQ account with literally zero permissions could still list and monitor other people's queues, because the "does this exist?" check forgot to ask whether you were allowed to know.
RabbitMQ lets a client "passively declare" a queue or exchange, a check-if-it-exists operation. That operation forgot to verify the user's permissions. So an authenticated user who is supposed to see nothing could still probe for queues and exchanges by name and pull back their statistics: how many messages are waiting, how many consumers are attached. It is information disclosure, not message theft or tampering. But in a shared environment, that information is reconnaissance: leaking naming conventions, business activity, and intelligence for a more targeted follow-on attack.
This bug has been in the codebase since RabbitMQ 3.13.0, introduced in early 2024.
Why it happened
A coding mistake in the channel handler (deps/rabbit/src/rabbit_channel.erl). The passive queue.declare and exchange.declare paths ignored the authorization context: the parameters were prefixed with an underscore, the Erlang convention for "deliberately unused," so the usual permission check never ran. Every comparable operation on the same data (queue.delete, basic.consume, basic.publish) did the check correctly. Passive declare was the lone exception: the kind of one-line inconsistency that is easy for a human eye to slide past, and rewarding for a system that compares paths side by side.
The attacker's path: from nothing to a map of the vhost
- Attacker holds a valid but powerless account on a shared virtual host (configure/write/read all empty).
- Attacker opens an AMQP connection and issues a passive queue.declare for a guessed or known queue name.
- The server skips the permission check and confirms the queue exists, returning its message and consumer counts.
- Attacker repeats across queue and exchange names to map the whole virtual host.
- Attacker watches message counts over time to infer business activity and backlog: intelligence for a follow-on attack.
Who is exposed
Multi-tenant environments where several applications or teams share one virtual host and rely on RabbitMQ's per-user permissions to keep them apart. There, the permission model is the only wall between tenants, and this bug puts a hole in it. A low-privilege or zero-permission account can map out and monitor everyone else's queues.
The fix
Upgrade to a patched release (4.3.0, 4.2.6, 4.1.11, 4.0.20, or 3.13.15). The fix makes passive declare honor permissions: the patched handlers now call check_configure_permitted(QueueName, User, AuthzContext) before returning anything. There is no configuration toggle to work around it, and there is no WAF rule or sensor for this one. Until you can patch, give tenants of differing trust their own virtual hosts rather than sharing one, so enumeration within a vhost no longer crosses a trust boundary.
Note that brokers are long-lived infrastructure that operators are often reluctant to restart, which means upgrades tend to lag well behind release. Prioritize this one.
What Miggo Recommends
Patch immediately. Upgrade RabbitMQ to 4.3.0, 4.2.6, 4.1.11, 4.0.20, or 3.13.15. Both CVEs are fixed in these releases.
Rotate the OAuth client secret. For CVE-2026-57219, assume the secret leaked if your management interface was ever reachable by an untrusted network. Patching removes the endpoint; it does not invalidate an already-exposed credential.
Keep port 15672 off untrusted networks. The management interface should never be exposed to the internet or to untrusted tenants.
Separate tenants by virtual host. For CVE-2026-57221, give tenants of differing trust their own vhosts rather than sharing one, and review per-user permissions on shared vhosts.
Mind frozen images. Pinned container images, Helm charts, and RabbitMQ embedded inside other products keep vulnerable versions alive long after the upstream fix. Check those too.
Bridge the gap with a WAF rule (CVE-2026-57219 only). If you can't patch the secret-leak issue immediately, Miggo's WAF rule blocks all access to the vulnerable endpoint on unpatched instances and covers the issue completely. For CVE-2026-57221, there is no WAF or sensor mitigation: the only fix is upgrading to a patched version.
Conclusion
Neither of these RabbitMQ bugs is exotic. One is a forgotten endpoint that authorizes differently from its neighbors. The other is a single check that one operation skipped while all its siblings performed it. They sat in the codebase for over two years. They are precisely the kind of quiet, systemic inconsistency that hides in mature, widely deployed software: the kind a human reviewer reads past, and a single-pass tool fails to compare against everything around it.
As autonomous vulnerability research matures, the teams that keep finding bugs like these won't just be the ones with the most capable model. They'll be the ones whose systems search broadly, remember what didn't work, demand evidence before raising an alarm, and encode real security methodology into how they look. VulnHunter found these two in a day each. We think that's a preview of how a lot of the application layer is going to get audited from here on out.
References
- CVE-2026-57219 advisory: https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-pj24-8j6m-vq9q
- CVE-2026-57221 advisory: https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-9q2j-2hq8-22r2
