Two Security Flaws in RabbitMQ Could Let Attackers Steal Login Secrets and Take Over Corporate Messaging Systems
A widely used software tool that moves data between business applications has patched two vulnerabilities, one of which could hand criminals full control over the system without a password.
Key points
- RabbitMQ, downloaded more than 15 million times a year, patched two security flaws discovered by researchers at Miggo Security.
- The more serious flaw, CVE-2026-57219, scored 8.7 out of 10 for severity and let anyone on the network steal an authentication secret without logging in.
- Fixed versions are 3.13.15, 4.0.20, 4.1.11, and 4.2.6, released to cover all supported branches of the software.
- A second flaw, CVE-2026-57221, let low-privileged users map internal systems they were never supposed to see.
- Broadcom's Tanzu division maintains RabbitMQ and did not respond to a request for comment first reported by CSO Online.
RabbitMQ is plumbing. Not exciting plumbing, but essential plumbing. It's the open-source software, meaning software whose code is freely available and shared, that shuttles data between different parts of a business application: orders, payments, login events, internal notifications. If your company's systems talk to each other, something like RabbitMQ is probably in the middle.
Two vulnerabilities in that software have now been patched. Researchers at Miggo Security found both. Neither is a ransomware incident. Both are the kind of quiet, structural flaw that makes future attacks much easier.
How did the hackers get in?
They didn't need to "get in" in the traditional sense. The first flaw, CVE-2026-57219, required no password at all. An old, forgotten management endpoint called GET/api/auth was still answering requests from the open network, handing out RabbitMQ's OAuth client secret: a private credential used to prove the software's identity to login providers like Microsoft Entra ID, Auth0, or Keycloak. With that secret, a criminal could generate an administrator token and take full control of the broker.
Full control means reading messages, changing settings, creating accounts, and altering the configuration of every application that relies on the system. Miggo scored the flaw 8.7 out of 10 for severity. The fix was blunt: the obsolete endpoint was deleted entirely, with OAuth configuration now delivered through an authenticated mechanism that no longer exposes the secret over HTTP.
The second flaw, CVE-2026-57221, is an authorisation bypass, meaning a check that should have blocked low-level users from seeing certain information was simply skipped. Attackers still needed valid credentials. Even so, an account with no real permissions could see whether message queues and exchanges (the internal channels data travels through) existed, how many messages were waiting, and how busy the system was. No message contents were exposed and nothing could be changed, but that kind of map can help criminals plan a targeted attack later. There's no configuration workaround for this one; upgrading is the only fix.
Both flaws affect RabbitMQ releases going back to version 3.13.0, introduced in early 2024. Our 7 July report on the BeyondTrust pre-authentication bugs is a useful comparison: unauthenticated access flaws are landing fast this quarter.
Should organisations upgrade immediately?
Yes. Upgrade to 3.13.15, 4.0.20, 4.1.11, or 4.2.6. Rotate any OAuth client secrets that may have been exposed. Keep the RabbitMQ management interface off public networks. Until patching's done, isolate tenants into separate virtual hosts inside the software.
Ordinary customers of businesses running RabbitMQ aren't directly at risk. But if a criminal exploited CVE-2026-57219 and took control of a broker, the order and payment data those systems carry could be at risk downstream. The CVE number is new; the attack pattern isn't.
