vulnerability
RabbitMQ Bugs Leak OAuth Secrets and Cross-Tenant Data
2026-07-15
Two access-control flaws in RabbitMQ, the open source message broker that quietly runs behind an enormous amount of production infrastructure, sat undiscovered in the codebase for close to two years before researchers at Miggo surfaced them.
The headline bug, CVE-2026-57219, is the kind of thing that makes you wince. The authorisation check on one management endpoint was hard-coded to always return true. Every other sensitive endpoint had a proper check. This one just waved everyone through. A single unauthenticated request was enough to pull the broker's OAuth client secret.
If the management port has ever been reachable from an untrusted network, whether that's a multi-tenant cloud deployment or a UI that got quietly exposed to the internet by someone who thought they'd locked it down, that secret is a straight path to full broker takeover.
The second bug is arguably worse for anyone running shared infrastructure
The companion flaw lets any authenticated user read data belonging to other tenants on the same broker. For MSPs or platform teams running a single RabbitMQ instance across multiple customers, that's a tenancy boundary that turned out not to be much of a boundary at all.
Both issues affect RabbitMQ 3.13.0 onwards. Fixes are in 4.3.0, 4.2.6, 4.1.11, 4.0.20 and 3.13.15. Miggo says there's no evidence either bug was exploited before disclosure, though absence of evidence in a two-year-old vulnerability is doing some heavy lifting.
What Miggo recommends
- Patch to a fixed version.
- Rotate the OAuth client secret if the management interface has ever been internet-reachable, regardless of patch status.
- Lock down port 15672 so it isn't exposed to untrusted networks.
- Separate tenants by virtual host rather than relying on user permissions alone.
- Add firewall rules for the vulnerable endpoint on any instance you can't patch immediately.
And while you're in there
The same round of updates also cleans up two critical bugs scoring 9.1 and 9.2. One lets an attacker bypass TLS client authentication. The other lets someone positioned in the middle of a connection forge JWKS responses, which means the broker will happily accept arbitrary JWTs signed by whoever forged them.
Neither of those made the headline, but either would ruin a week.
RabbitMQ tends to be one of those systems that gets installed, configured once, and then quietly hums along for years without anyone touching it. That's exactly the profile of software where two-year-old auth bugs go unnoticed. Worth a look at where yours are running, particularly the ones in shared environments.