Hackers Can Exploit RabbitMQ OAuth Flaw to Access Every Message, Queue, and User

Security researchers have disclosed two access-control vulnerabilities in RabbitMQ, the open-source message broker used in an estimated 8% of all containers running today, that could allow attackers to seize full administrative control of a broker or silently map out sensitive queue data across shared tenants.

Both flaws were discovered by Miggo Security’s autonomous research system, VulnHunter, and have been present in RabbitMQ’s codebase since version 3.13.0 shipped in early 2024. Following coordinated disclosure with RabbitMQ maintainers, patches are now available.

Hackers Can Exploit RabbitMQ OAuth Flaw

The more severe flaw (CVSS v4.0 8.7) lives in an obsolete management API endpoint, GET /api/auth, which returned the broker’s OAuth 2 configuration to any unauthenticated requester.

When operators configured management.oauth_client_secret for identity providers like Auth0, Entra ID, Keycloak, or UAA, that confidential secret was included in the plaintext response.

The technical root cause traces to rabbit_mgmt_wm_auth.erl, where the endpoint’s is_authorized/2 callback was hard-coded to always return true, bypassing authentication entirely.

An attacker needs only network access to port 15672 to retrieve the secret, then exchange it with the identity provider for an administrator token, granting complete control over messages, queues, users, and broker configuration.

The full disclosure parameters, technical root causes, and systemic risk assessments are mapped out inside the publication Full Broker Takeover, No Login Required: Miggo Discovers Critical RabbitMQ Vulnerabilities Putting Application Data at Risk.

The second flaw (CVSS v4.0 5.3, CWE-862) allows any authenticated user, even one with zero permissions, to enumerate queues and exchanges and read their statistics.

The bug resides in rabbit_channel.erl, where the “passive declare” existence-check operation skipped its permission validation, unlike comparable operations such as queue.delete or basic.publish.

In shared, multi-tenant RabbitMQ deployments, this lets low-privilege accounts reconnoiter naming conventions, message volumes, and business activity across tenants who share a virtual host, information useful for follow-on attacks.

Unchecked backend authorization flaws like this can severely undermine corporate tenancy, echoing systemic access risks frequently observed during large-scale software deserialization and credential compromises.

Identified CVE Tracker	Target Architecture Script	Exploitation Mechanism	Core Operational Risk
CVE-2026-57219	rabbit_mgmt_wm_auth.erl	is_authorized/2 callback hardcoded to true bypass	Unauthenticated plaintext OAuth client secret extraction
CVE-2026-57221	rabbit_channel.erl	Passive declare verification missing permission checks	Unauthorized tenant reconnaissance and metadata harvesting

Both vulnerabilities are fixed in RabbitMQ 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. Miggo recommends:

• Apply Patches: Immediately update to an upstream supported release.
• Credentials Rotation: Rotate OAuth client secrets, since patching removes the vulnerable endpoint but does not invalidate an already-leaked credential.
• Network Hardening: Keep the management port (15672) entirely off untrusted or public networks.
• Tenant Isolation: Separate tenants strictly by virtual host rather than sharing a single vhost across trust boundaries.
• Image Audits: Audit pinned container images and Helm charts, which can keep vulnerable versions running long after the upstream fix ships.

For CVE-2026-57219, Miggo has published a WAF rule blocking access to the vulnerable endpoint as a stopgap. No equivalent mitigation exists for CVE-2026-57221; upgrading is the only permanent fix.

To protect message topologies effectively, engineers must adopt continuous defense strategies, such as integrating rigorous API security testing models across microservices.

No in-the-wild exploitation has been observed for either CVE. Both are described as “inconsistency” bugs, subtle deviations from a codebase’s own established authorization patterns, the kind of issue that widescale, side-by-side automated analysis is increasingly suited to catch.