RabbitMQ Flaw Exposes OAuth Secrets, Putting Enterprise Deployments at Risk

Security researchers at Miggo have disclosed a vulnerability in RabbitMQ that could let attackers extract the message broker's confidential OAuth secret, raising serious concerns for organizations relying on the platform.

RabbitMQ is a widely-used open source message broker responsible for routing, buffering, and distributing messages between applications, enabling them to communicate asynchronously.

The vulnerability, designated CVE-2026-57219 and rated 8.7 on the CVSS scale, stems from a management endpoint that hands over the OAuth secret to any requester—no login required.

According to Miggo, the issue traces back to a deprecated endpoint within RabbitMQ's web-based management interface. It becomes exploitable specifically in setups where administrators have configured the broker's confidential credentials for identity provider authentication.

Miggo explained that anyone able to reach the management port could pull the secret, then leverage it to pose as the broker when communicating with the identity provider—ultimately securing an administrator-level token.

The risk is most pronounced in environments using OAuth 2.0 or OIDC identity providers—platforms like Auth0, Azure AD/Entra ID, Keycloak, or UAA—since these are the typical setups where the exposed secret becomes usable. In such cases, an attacker armed with the administrator token could seize control over user accounts, message queues, and broader broker configuration settings, according to the firm.

Deployments without a configured client secret aren't at risk here, simply because there's nothing to steal in the first place. Similarly, RabbitMQ setups that don't have the management plugin enabled sit outside the danger zone entirely.

Miggo pointed out that the greatest exposure comes when the management port is accessible from an untrusted network—think multi-tenant cloud environments, or cases where a management interface has been inadvertently left open to the public internet.

The flaw, CVE-2026-57219, dates back to early 2024 when it was introduced in RabbitMQ 3.13.0. Fixes are now available in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.

Alongside this fix, the same round of updates resolves CVE-2026-57221, a medium-severity authorization gap (CVSS 5.3) that lets any logged-in user browse queues and exchanges and pull their statistics—without needing the proper permissions to do so.

Miggo warns that this second flaw could serve reconnaissance purposes: an attacker could use it to map out an organization's virtual host structure, piece together clues about business operations, and gather intel to inform future attacks. The danger is especially pronounced in shared multi-tenant setups, where a single virtual host serves multiple applications or teams simultaneously.

Miggo's recommended response is straightforward: patch affected RabbitMQ instances as soon as possible. Where immediate patching isn't feasible, restrict access to vulnerable systems, keep the management interface away from public internet exposure, apply network segmentation, and rotate any OAuth client secrets that may have been compromised. So far, there's no indication either vulnerability has been exploited in real-world attacks.