CVE-2026-67404 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, When no CA bundle is available, ssl_options/1 falls back to [{verify, verify_none}] with no warning. An attacker in a man-in-the-middle position can forge the JWKS response, which leads the broker to accept arbitrary JWTs. Preconditions include The OAuth2 plugin must be in use with no cacertfile configured and the OS CA bundle empty or unreadable (for example, in a minimal container), and the attacker must hold a network man-in-the-middle position.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a robust messaging and streaming broker widely deployed in enterprise environments to facilitate asynchronous communication between distributed systems. A critical security vulnerability exists within the SSL/TLS configuration logic of RabbitMQ versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. The flaw resides in how the ssl_options/1 function handles certificate verification when no Certificate Authority bundle is explicitly configured by the administrator or available from the operating system. In such scenarios, rather than failing securely or issuing a warning about the lack of trust anchors, the broker silently falls back to setting the verify option to verify_none. This default behavior effectively disables server certificate validation for SSL/TLS connections that rely on this configuration path, creating a significant blind spot in the security posture of deployments using minimal container images or environments where OS CA bundles are empty or unreadable.
The operational impact of this vulnerability is severe when the RabbitMQ OAuth2 plugin is enabled and configured to use JSON Web Tokens (JWTs) for authentication without an explicitly defined cacertfile. In these specific configurations, the broker relies on fetching a JWKS response from a remote identity provider to validate incoming JWT signatures. Because SSL verification is disabled due to the missing CA bundle, an attacker positioned in a man-in-the-middle position can intercept and forge this JWKS response. By serving a maliciously crafted JWKS document containing their own public key, the attacker tricks the RabbitMQ broker into accepting arbitrary JWTs signed with the attacker's private key. This allows the adversary to impersonate any user or service that authenticates via OAuth2, effectively bypassing authentication controls entirely and gaining unauthorized access to queues, exchanges, and messages within the messaging infrastructure.
This vulnerability aligns closely with CWE-295 Improper Certificate Validation, as the system fails to properly validate the authenticity of the server's certificate during the TLS handshake when trust anchors are absent. Furthermore, it relates to CWE-613 Insufficient Session Expiration in the context of authentication bypass, although the root cause is strictly cryptographic validation failure. From an ATT&CK perspective, this flaw facilitates Initial Access through Tactic TA0001 and Technique T1078 Valid Accounts, as well as Defense Evasion via T1550 Use Alternate Authentication Material, since the attacker substitutes legitimate authentication tokens with forged ones derived from the compromised JWKS endpoint. The severity is compounded by the fact that many modern deployments utilize lightweight containers where CA bundles are often omitted to reduce image size, inadvertently triggering this fallback behavior without administrator awareness.
Mitigation requires immediate action for all affected versions. Organizations must upgrade RabbitMQ to version 3.13.15 or later in the 3.13 series, or to any of the fixed minor releases within the 4.x branch (4.0.20, 4.1.11, 4.2.6, or 4.3.0). For deployments that cannot be upgraded immediately, a critical workaround is to explicitly configure the cacertfile option in the RabbitMQ configuration file to point to a valid and readable CA bundle on the host system. This ensures that ssl_options/1 does not fall back to verify_none even if the OS-level CA store is inaccessible. Additionally, administrators should audit their container images to ensure they include standard CA certificates or explicitly mount them at runtime. Regular monitoring of TLS connection logs for anomalies and ensuring that network segmentation limits man-in-the-middle capabilities can provide additional layers of defense while remediation efforts are underway.