CVE-2026-67409: RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.
Other sources
RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.13.7-11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.3 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.9 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.14 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.23 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.18
Event History
Frequently Asked Questions
Which deployments are exposed?
RabbitMQ deployments using OAuth2/JWT authentication with JWKS signing keys are exposed if they run versions from 3.13.0 before the listed fixed releases: 3.13.18, 4.0.23, 4.1.14, 4.2.9, or 4.3.3.
What conditions are required to trigger the authentication outage?
The RabbitMQ instance must fetch JWKS data from its OAuth2 provider, and that endpoint must return a non-200 HTTP response whose body is valid JSON but does not contain a keys field. The affected code processes that response as if it were a successful JWKS response.
How can an administrator recognize that this condition has occurred?
After the cached signing keys are destroyed, OAuth2/JWT authentication fails for all users. The failure persists because the previously cached keys have been removed.