RabbitMQ Bugs Could Have Handed Attackers the Keys to Corporate Messaging

Key points

• Researchers at Miggo disclosed two access control flaws in RabbitMQ, a widely used open source messaging service that shuttles data between corporate applications.
• One flaw leaks the broker's confidential OAuth client secret, the private password apps use to prove who they are.
• The second flaw lets one customer on a shared RabbitMQ system see queue information belonging to a separate customer, breaking tenant isolation.
• Miggo reported the bugs to the RabbitMQ maintainers, who have issued fixes; administrators are urged to update.
• No confirmed exploitation in the wild has been reported at the time of disclosure.

A pair of newly disclosed bugs in RabbitMQ, the open source software that thousands of companies use to pass messages between their internal applications, could have let attackers steal login secrets and snoop across customer boundaries.

The flaws were found by the security firm Miggo and first reported by The Hacker News.

RabbitMQ is what engineers call a message broker. Think of it as the internal post office inside a company's software: one app drops a note in, another app picks it up. Banks, airlines, retailers and healthcare firms lean on it heavily. If the post office is broken into, a lot of mail is exposed.

What did the researchers actually find?

Miggo found two access control problems, meaning bugs in the rules that decide who is allowed to see or do what.

The first bug leaks the broker's OAuth client secret. OAuth is the standard system that lets apps log in to each other without sharing full passwords. The client secret is the private key that proves an app is who it says it is. If a criminal grabs that secret, they can impersonate the messaging service to the wider corporate network. From there, they can potentially take over the broker itself and read, redirect or delete the messages flowing through it.

The second bug is about tenant isolation. Many companies run RabbitMQ in a shared setup where different teams, or different customers, each get their own walled off section called a virtual host. Miggo showed that a user in one section could pull metadata about queues in another section. Metadata here means information about the messages, such as names, sizes and routing, not always the message contents themselves. Still, it is the kind of leak that shatters the promise of a multi-tenant system.

Who is affected?

Any organisation running a vulnerable version of RabbitMQ, especially in a shared or cloud hosted arrangement, is in scope. That includes the many enterprises that use RabbitMQ behind the scenes to power order systems, chat apps, banking back ends and logistics platforms.

Ordinary customers of those companies do not need to do anything themselves. There are no passwords for the public to change here. This is a job for the IT teams running the software.

What should administrators do now?

Update. The RabbitMQ maintainers have shipped patched versions, and Miggo's advisory walks through the fix. Teams should also rotate their OAuth client secrets after patching, on the assumption the old ones may already be known to someone who should not have them.

It is worth checking logs for odd administrative activity, unexpected new users, or queue lookups crossing tenant lines. If a broker was exposed to the public internet without strict network controls, treat it as potentially touched and investigate accordingly.

There is no public evidence yet that criminal groups have used these bugs. That window tends to be short. Once technical write ups circulate, opportunistic scanning follows within days, not months.

For most readers, the practical takeaway is simpler. The plumbing that carries your bank transfer, your delivery notification or your hospital record is only as trustworthy as the people patching it. This week, those people have work to do.