CVE-2026-57219: RabbitMQ OAuth Secret Disclosure Flaw

CVE-2026-57219 Overview

CVE-2026-57219 is an information disclosure vulnerability in RabbitMQ, an open source messaging and streaming broker maintained under the Broadcom RabbitMQ Server product family. The obsolete GET /api/auth endpoint in the management plugin can disclose the OAuth 2 client secret when the broker is configured with management.oauth_client_secret. Unauthenticated network callers can retrieve the secret whenever the management plugin and that OAuth configuration are both enabled. The issue is tracked under [CWE-200] Information Exposure and [CWE-522] Insufficiently Protected Credentials. Affected versions include all releases prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

Critical Impact
Unauthenticated attackers can retrieve the OAuth 2 client secret over the network, enabling impersonation of the RabbitMQ management application against the configured identity provider.

Affected Products

Broadcom RabbitMQ Server versions prior to 3.13.15
Broadcom RabbitMQ Server 4.0.x prior to 4.0.20, and 4.1.x prior to 4.1.11
Broadcom RabbitMQ Server 4.2.x prior to 4.2.6

Discovery Timeline

2026-07-10 - CVE-2026-57219 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-57219

Vulnerability Analysis

RabbitMQ's management plugin exposes an HTTP API for administrators and integrations. The legacy GET /api/auth endpoint was designed to return OAuth 2 configuration metadata such as oauth_enabled, oauth_client_id, and oauth_provider_url. When operators configured management.oauth_client_secret, the endpoint also returned the secret value in its JSON response. The endpoint did not require authentication, so any network caller able to reach the management HTTP listener could request the resource and read the credential.

OAuth 2 client secrets are shared credentials between the RabbitMQ management UI and the identity provider (IdP). An attacker holding the secret and the oauth_client_id can request tokens from the IdP as if they were the RabbitMQ management application. Depending on IdP configuration, this may allow token minting, callback abuse, or lateral access to other resources that trust the same client.

Root Cause

The root cause is a design flaw in an obsolete endpoint that returned sensitive configuration data without authorization. The management dispatcher registered /auth in rabbit_mgmt_dispatcher.erl and routed it to rabbit_mgmt_wm_auth, which serialized the OAuth client secret into the response body alongside non-sensitive fields.

Attack Vector

Exploitation requires only network reachability to the RabbitMQ management HTTP port (default TCP 15672) on an instance where management.oauth_client_secret is set. An attacker issues an unauthenticated GET request against /api/auth and parses the JSON response for the leaked secret.

text

// Patch: remove the /auth route from the management dispatcher
     {"/reset",                                                rabbit_mgmt_wm_reset, []},
     {"/reset/:node",                                          rabbit_mgmt_wm_reset, []},
     {"/rebalance/queues",                                     rabbit_mgmt_wm_rebalance_queues, [{queues, all}]},
-    {"/auth",                                                 rabbit_mgmt_wm_auth, []},
     {"/auth/attempts/:node",                                  rabbit_mgmt_wm_auth_attempts, [all]},
     {"/auth/attempts/:node/source",                           rabbit_mgmt_wm_auth_attempts, [by_source]},
     {"/login",                                                rabbit_mgmt_wm_login, []},

Source: rabbitmq-server commit aa387c4. The fix removes the deprecated route from deps/rabbitmq_management/src/rabbit_mgmt_dispatcher.erl and deletes the corresponding documentation entry in deps/rabbitmq_management/priv/www/api/index.html.

Detection Methods for CVE-2026-57219

Indicators of Compromise

HTTP GET requests to /api/auth on the RabbitMQ management port (default 15672) originating from unauthenticated sources
Access log entries where /api/auth returned HTTP 200 with a response body containing oauth_client_secret prior to patching
Unexpected OAuth token issuance for the RabbitMQ management client_id from unfamiliar source IPs

Detection Strategies

Inspect RabbitMQ management access logs and reverse-proxy logs for historical GET /api/auth requests, especially without an Authorization header
Correlate identity provider audit logs for token grants tied to the RabbitMQ oauth_client_id and flag issuances from IPs outside the management plane
Use the Singularity Data Lake to ingest RabbitMQ HTTP logs alongside IdP telemetry and query for /api/auth hits followed by token grants

Monitoring Recommendations

Alert on any request path /api/auth reaching a RabbitMQ node from outside management subnets
Monitor the running RabbitMQ version and flag hosts still on releases prior to 3.13.15, 4.0.20, 4.1.11, or 4.2.6
Track rotation events for the OAuth 2 client secret and validate that stale values are no longer accepted by the IdP

How to Mitigate CVE-2026-57219

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, or 4.2.6, matching your current release branch
Rotate the OAuth 2 client secret configured in management.oauth_client_secret at the identity provider, then update RabbitMQ configuration
Restrict network access to the management HTTP listener (default TCP 15672) to trusted administrative networks
Review IdP audit logs for token grants tied to the RabbitMQ management client_id and revoke any suspicious sessions

Patch Information

Broadcom's RabbitMQ maintainers fixed the issue by removing the deprecated /api/auth route and its documentation. The upstream fixes are tracked in pull request #16083 and pull request #16086, landed in commits 98b1daf and aa387c4, and shipped in RabbitMQ v4.2.6. See GHSA-pj24-8j6m-vq9q for the coordinated advisory.

Workarounds

Remove management.oauth_client_secret from rabbitmq.conf if OAuth 2 login for the management UI is not required
Block or filter the /api/auth path at a fronting reverse proxy or WAF until the upgrade is applied
Bind the management HTTP listener to a management-only interface and enforce firewall rules limiting access to administrators

bash

# Example NGINX front-end rule to block the deprecated endpoint
location = /api/auth {
    return 404;
}

# Example iptables rule restricting management port access
iptables -A INPUT -p tcp --dport 15672 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 15672 -j DROP