CVE-2026-57219: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-57219 is an unauthenticated OAuth 2 client secret disclosure vulnerability in RabbitMQ's management plugin. An obsolete HTTP API endpoint, GET /api/auth, exposes the OAuth 2 client secret (management.oauth_client_secret) to unauthenticated callers on installations where both the management plugin and OAuth 2 with that specific configuration key are enabled. The vulnerability affects RabbitMQ versions 3.13.0–3.13.14, 4.0.0–4.0.19, 4.1.0–4.1.10, and 4.2.0–4.2.5. It was published on July 10, 2026, with patches released shortly after. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, Feedly).

The root cause is the retention of a legacy GET /api/auth endpoint (implemented in rabbit_mgmt_wm_auth.erl) that was superseded by the bootstrap.js mechanism introduced in 2023 but never removed. The is_authorized/2 handler for this endpoint unconditionally returned {true, ReqData, Context}, meaning no authentication check was enforced before returning OAuth configuration data including the client secret. This maps to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-522 (Insufficiently Protected Credentials). The vulnerability is only exploitable when the rabbitmq_management plugin is enabled and management.oauth_client_secret is configured; installations using other OAuth 2 grant types or not using OAuth 2 at all are unaffected (GitHub Advisory, GitHub PR #16083, Commit aa387c4).

An unauthenticated remote attacker who can reach the RabbitMQ management API can retrieve the OAuth 2 client secret, which can then be used to impersonate the RabbitMQ broker as an OAuth 2 client, potentially enabling full broker takeover — including access to all message queues, user data, and tenant information. The confidentiality impact is high, as the exposed credential can facilitate lateral movement within the identity provider's scope and unauthorized access to downstream systems that trust the OAuth 2 client. Availability and integrity of the RabbitMQ broker itself are not directly impacted by the disclosure alone, but secondary exploitation using the stolen secret could affect both (GitHub Advisory, CSO Online).

No public proof-of-concept exploit code has been identified, and there is no evidence of active in-the-wild exploitation as of the time of reporting (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.0033 (0.33%), indicating a low probability of exploitation in the near term. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable, reflecting the specific configuration prerequisites required (Feedly). The vulnerability was discovered and reported by researcher liad-miggo (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible RabbitMQ instances with the management plugin enabled (default port 15672) using tools like Shodan, Censys, or nmap. Target versions 3.13.0–3.13.14, 4.0.0–4.0.19, 4.1.0–4.1.10, or 4.2.0–4.2.5.
2. Probe the vulnerable endpoint: Send an unauthenticated HTTP GET request to the management API: curl -s http://<rabbitmq-host>:15672/api/auth
3. Extract the OAuth 2 client secret: If the target is configured with management.oauth_client_secret, the response will include the OAuth 2 client ID, provider URL, and client secret in plaintext JSON, e.g., {"oauth_enabled":true,"oauth_client_id":"...","oauth_client_secret":"...","oauth_provider_url":"..."}.
4. Leverage the stolen secret: Use the obtained client secret to authenticate as the RabbitMQ OAuth 2 client against the configured identity provider, potentially obtaining access tokens that grant administrative access to the broker and all its resources (GitHub Advisory, Miggo Research).

• Network: Unauthenticated HTTP GET requests to /api/auth on the RabbitMQ management port (default 15672 or 15671 for TLS) from unexpected source IPs; unusual volume of requests to this endpoint from external or untrusted networks.
• Logs: RabbitMQ management access logs showing GET /api/auth requests with HTTP 200 responses from unauthenticated clients; absence of Authorization headers in requests to this endpoint.
• Identity Provider Logs: Unexpected OAuth 2 client credential grant flows initiated using the RabbitMQ client ID from unfamiliar IP addresses or at unusual times, potentially indicating use of the stolen secret.
• RabbitMQ Audit Logs: Unusual administrative actions (queue creation/deletion, user management, policy changes) performed via OAuth 2 tokens obtained outside normal operational patterns.

Upgrade RabbitMQ to a patched version: 3.13.15, 4.0.20, 4.1.11, or 4.2.6, which remove the vulnerable GET /api/auth endpoint entirely (GitHub Advisory). If immediate upgrade is not possible, the following workarounds can mitigate the risk:

• Disable the rabbitmq_auth_backend_oauth2 plugin and switch to a different authentication backend.
• Switch to an OAuth 2 grant type that does not require management.oauth_client_secret.
• Disable the rabbitmq_management plugin and use Prometheus/Grafana for monitoring instead.
• Restrict network access to the management plugin endpoints (port 15672/15671) to trusted networks only using firewall rules.

The vulnerability received notable coverage from security media outlets including The Hacker News, SC World, SecurityWeek, CSO Online, and GBHackers, with several articles highlighting the potential for full broker takeover (The Hacker News, SC World, SecurityWeek). Miggo Research, the firm credited with discovery, published a detailed blog post describing the vulnerability as enabling "full broker takeover, no login required" (Miggo Research). Emerging Threats updated its ruleset to include detection for this vulnerability on July 14, 2026 (Emerging Threats). The vulnerability was also included in The Hacker News weekly security recap, indicating broad community awareness (The Hacker News Weekly).