CVE-2026-67404: RabbitMQ: OAuth2 silent verify_none fallback for JWKS fetch
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, ssloptions/1 falls back to [{verify, verifynone}] 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the OAuth2 plugin are exposed only when no cacertfile is configured and the operating system CA bundle is empty or unreadable, such as in a minimal container. The affected broker must also be running a version earlier than 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0.
What does an attacker need to exploit it?
An attacker must be in a network man-in-the-middle position between the broker and the JWKS endpoint. In the affected CA configuration, they can forge the JWKS response and cause the broker to accept arbitrary JWTs.
What can be done if upgrading is not immediately possible?
Configure a cacertfile for the OAuth2 plugin or ensure that the operating system CA bundle is present and readable. This prevents the condition in which TLS verification silently falls back to verify_none.
How can I determine whether my broker is currently at risk?
Check whether the OAuth2 plugin is enabled, whether a cacertfile is configured, and whether the OS CA bundle is available and readable in the broker runtime environment. A broker meeting those conditions and running an affected version is at risk if an attacker can obtain a network man-in-the-middle position.