CVE-2026-67409: CWE-252: Unchecked Return Value in rabbitmq rabbitmq-server
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.
AI Analysis
Technical Summary
The vulnerability CVE-2026-67409 in rabbitmq-server arises from the JWKS fetching code in uaajwt.erl ignoring the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Specifically, the Erlang httpc module returns a tuple including the HTTP status code, but the code pattern matches any successful HTTP transaction without validating the status code. Consequently, if the JWKS endpoint returns an error response (4xx or 5xx) with a valid JSON body missing the 'keys' field, the cached signing keys are destroyed. This leads to a persistent denial of service for OAuth2/JWT authentication, affecting all users until a successful JWKS refresh. The vulnerability affects multiple RabbitMQ versions prior to fixed releases 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.
Potential Impact
An attacker can cause a denial of service for all OAuth2-authenticated users on the affected RabbitMQ server by triggering the JWKS endpoint to return an error response that leads to destruction of cached signing keys. This results in persistent authentication failures until a successful JWKS refresh occurs. The impact is a complete denial of OAuth2 authentication, effectively locking out all legitimate users relying on this mechanism.
Mitigation Recommendations
This vulnerability is fixed in RabbitMQ versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18. Users should upgrade to these or later versions to remediate the issue. No other mitigation or temporary workaround is indicated in the available data.
CVE-2026-67409: CWE-252: Unchecked Return Value in rabbitmq rabbitmq-server
Description
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.
CVSS v4.0
Score 8.2high
Affected software
rabbitmq
rabbitmq-server
pkg:github/rabbitmq/rabbitmq-serverRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability CVE-2026-67409 in rabbitmq-server arises from the JWKS fetching code in uaajwt.erl ignoring the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Specifically, the Erlang httpc module returns a tuple including the HTTP status code, but the code pattern matches any successful HTTP transaction without validating the status code. Consequently, if the JWKS endpoint returns an error response (4xx or 5xx) with a valid JSON body missing the 'keys' field, the cached signing keys are destroyed. This leads to a persistent denial of service for OAuth2/JWT authentication, affecting all users until a successful JWKS refresh. The vulnerability affects multiple RabbitMQ versions prior to fixed releases 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.
Potential Impact
An attacker can cause a denial of service for all OAuth2-authenticated users on the affected RabbitMQ server by triggering the JWKS endpoint to return an error response that leads to destruction of cached signing keys. This results in persistent authentication failures until a successful JWKS refresh occurs. The impact is a complete denial of OAuth2 authentication, effectively locking out all legitimate users relying on this mechanism.
Mitigation Recommendations
This vulnerability is fixed in RabbitMQ versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18. Users should upgrade to these or later versions to remediate the issue. No other mitigation or temporary workaround is indicated in the available data.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-07-29T15:02:20.412Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6ab6a25cf7a7c54106018e36
Added to database: 09/25/2026, 16:33:32 UTC
Last enriched: 09/25/2026, 16:47:50 UTC
Last updated: 09/26/2026, 02:45:07 UTC
Views: 14
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.