CVE-2026-67409 in RabbitMQ
Summary
by MITRE • 09/25/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified as CWE-252, Unchecked Return Value, affects the JSON Web Token authentication backend for RabbitMQ in versions ranging from 3.13.0 up to specific patched releases including 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18. This flaw resides within the Java Web Key Set fetching mechanism implemented in the Erlang source files uaajwt.erl and uaajwks.erl. The core technical deficiency is that the application logic fails to validate the HTTP response status code when retrieving signing keys from an OAuth2 provider's JWKS endpoint. Instead of checking for a standard success indicator such as an HTTP 200 OK, the pattern matching in the Erlang httpc module treats any successful transaction tuple identically regardless of whether it represents a genuine retrieval or an error condition. This oversight allows non-2xx responses, including client errors like 403 Forbidden or server errors like 500 Internal Server Error, to be processed as if they contained valid key material.
The operational impact of this flaw is severe and manifests as a persistent authentication denial of service. When the JWKS endpoint returns an error response that contains a syntactically valid JSON body but lacks the expected keys field, the application logic interprets this absence not as a failure to fetch data, but as an explicit instruction to clear existing credentials. Consequently, all previously cached signing keys are destroyed from memory. This action results in a complete breakdown of OAuth2 and JWT authentication for every user attempting to connect to or interact with the RabbitMQ broker. Unlike transient network glitches that might resolve on retry, this state persists until the system successfully refreshes its JWKS data by receiving a response containing valid key material. An attacker can exploit this behavior to trigger a widespread outage affecting all legitimate users without needing direct access to user credentials.
From an attack perspective, this vulnerability aligns with ATT&CK technique T1498 Network Denial of Service, specifically the sub-technique related to resource exhaustion or service disruption through application logic exploitation. The amplification factor is significant because a single request targeting the JWKS endpoint can disable authentication for the entire cluster. This creates a high-value target for malicious actors seeking to disrupt messaging infrastructure availability. The vulnerability highlights critical risks in handling external dependencies and parsing untrusted data, where assumptions about response structure are not rigorously enforced against malformed or error-state inputs.
Mitigation strategies primarily involve upgrading RabbitMQ to one of the fixed versions listed above, which corrects the pattern matching logic to strictly validate HTTP status codes before processing JWKS payloads. In environments where immediate patching is not feasible, administrators should implement network-level controls such as firewall rules or reverse proxy configurations that ensure only successful responses from trusted OAuth2 providers reach the RabbitMQ instance. Additionally, configuring health checks and monitoring for authentication failures can help detect this condition early, allowing operators to manually trigger a JWKS refresh once connectivity with the identity provider is restored.