CVE-2026-67404: RabbitMQ OAuth2 Auth Bypass Vulnerability

CVE-2026-67404 Overview

RabbitMQ contains a certificate validation flaw [CWE-295] in its OAuth2 plugin JSON Web Key Set (JWKS) handling. When no Certificate Authority (CA) bundle is available, the ssl_options/1 function silently falls back to [{verify, verify_none}] without emitting a warning. An attacker positioned as a network man-in-the-middle can forge the JWKS response and cause the broker to accept arbitrary JSON Web Tokens (JWTs). The issue affects RabbitMQ deployments running the OAuth2 plugin without a configured cacertfile when the operating system CA bundle is empty or unreadable, a common condition in minimal container images.

Critical Impact
Successful exploitation lets an on-path attacker authenticate to the broker with forged JWTs, gaining the confidentiality, integrity, and availability of any account the tokens claim.

Affected Products

RabbitMQ broker versions prior to 3.13.15
RabbitMQ broker versions prior to 4.0.20, 4.1.11, and 4.2.6
RabbitMQ broker versions prior to 4.3.0 with the OAuth2 plugin enabled

Discovery Timeline

2026-09-23 - CVE-2026-67404 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-67404

Vulnerability Analysis

RabbitMQ's OAuth2 plugin validates access tokens by retrieving signing keys from a remote JWKS endpoint over HTTPS. The ssl_options/1 helper builds the TLS options used for that HTTPS request. When no CA bundle is provided through cacertfile and the system trust store is empty or unreadable, the helper returns [{verify, verify_none}] instead of failing closed. TLS negotiation then proceeds without peer certificate verification.

The silent fallback removes the trust anchor that OAuth2 relies on. An attacker who can intercept traffic between the broker and the identity provider can present any certificate, serve a forged JWKS document containing attacker-controlled keys, and sign JWTs that the broker accepts as valid. Authorization decisions inside RabbitMQ then follow the forged token's claims, including scopes and virtual host permissions.

Root Cause

The root cause is improper certificate validation in the TLS client configuration path used for JWKS retrieval. The code prefers availability over safety and does not raise an error or log a warning when it downgrades to verify_none. Minimal container images that ship without ca-certificates installed satisfy the precondition by default.

Attack Vector

Exploitation requires a network man-in-the-middle position between the RabbitMQ broker and the OAuth2 identity provider hosting the JWKS endpoint. The attacker intercepts the HTTPS request, presents any TLS certificate, and returns a JWKS document containing a public key under attacker control. The attacker then mints JWTs signed with the matching private key and presents them to RabbitMQ to obtain broker access at the privilege level encoded in the token.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-37wx-r6q9-6fhj for vendor technical details.

Detection Methods for CVE-2026-67404

Indicators of Compromise

Outbound HTTPS connections from RabbitMQ nodes to unexpected hosts resolving the configured JWKS URL.
Successful RabbitMQ authentications using OAuth2 tokens whose kid or issuer does not match the legitimate identity provider.
Broker logs showing OAuth2 authentication events immediately following JWKS retrieval from an unexpected IP address.

Detection Strategies

Audit RabbitMQ configuration for the OAuth2 plugin and confirm whether cacertfile is set and readable.
Inspect container images running RabbitMQ for a populated CA trust store, for example /etc/ssl/certs/ca-certificates.crt.
Correlate broker access grants with identity-provider issuance logs; missing correlations indicate forged tokens.

Monitoring Recommendations

Enable RabbitMQ debug logging for the OAuth2 backend and monitor JWKS fetch operations for TLS negotiation anomalies.
Alert on any RabbitMQ egress traffic to destinations other than the sanctioned identity provider.
Track new administrative actions performed by OAuth2-authenticated principals and validate them against expected workflows.

How to Mitigate CVE-2026-67404

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 or later, matching the deployed release branch.
Explicitly configure cacertfile in the OAuth2 plugin settings to point at a valid CA bundle covering the identity provider.
Install the ca-certificates package in RabbitMQ container images and verify the trust store is readable by the broker process.

Patch Information

The RabbitMQ project fixed the flaw in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. Release notes and code changes are documented in the GitHub RabbitMQ Release v4.2.6 and the GitHub Security Advisory GHSA-37wx-r6q9-6fhj.

Workarounds

Restrict broker egress with network policy so the broker can only reach the sanctioned JWKS endpoint over a trusted path.
Terminate the JWKS connection through an internal reverse proxy that enforces certificate pinning to the identity provider.
Disable the OAuth2 plugin until the patched release is deployed if a trusted CA path cannot be guaranteed.

bash

# Configuration example: explicitly set the CA bundle for OAuth2 JWKS validation
# rabbitmq.conf
auth_oauth2.resource_server_id = rabbitmq
auth_oauth2.jwks_url = https://idp.example.com/.well-known/jwks.json
auth_oauth2.https.cacertfile = /etc/ssl/certs/ca-bundle.crt
auth_oauth2.https.peer_verification = verify_peer
auth_oauth2.https.hostname_verification = wildcard