CVE-2026-67409

Executive Summary

CVE-2026-67409 is a denial-of-service vulnerability in RabbitMQ's OAuth2/JWT authentication backend. The JWKS (JSON Web Key Set) key fetching mechanism fails to validate HTTP response status codes, allowing non-200 responses to be processed as successful key retrievals. An attacker able to cause the OAuth2 provider's JWKS endpoint to return a valid-JSON error body without a keys field can destroy all cached signing keys, causing persistent authentication failure for all OAuth2/JWT users until a successful JWKS refresh occurs.

Technical Analysis

The vulnerability is classified as CWE-252 (Unchecked Return Value) and resides in the rabbitmq_auth_backend_oauth2 plugin's JWKS fetching logic. According to the NVD description, the affected code is in deps/rabbitmq_auth_backend_oauth2/src/uaajwt.erl (lines 50-63), deps/rabbitmq_auth_backend_oauth2/src/uaajwks.erl (lines 5-7), and deps/rabbitmq_auth_backend_oauth2/src/rabbit_oauth2_provider.erl (lines 98-107).

The core defect is in the Erlang httpc module response handling. The httpc module returns a tuple of the form {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The vulnerable code pattern {ok, {_, _, JwksBody}} matches ANY successful HTTP transaction regardless of the actual HTTP status code. This means a 404, 500, or any other non-200 response is treated identically to a 200 OK response.

When the JWKS endpoint returns an error response with a valid-JSON body lacking a keys field, the plugin interprets this as an authoritative key set containing no keys. Consequently, all previously cached signing keys are destroyed. Because RabbitMQ uses these cached JWKS keys to validate JWT signatures for OAuth2 authentication, the destruction of the key cache causes all OAuth2/JWT authentication attempts to fail persistently until a subsequent JWKS refresh succeeds.

This is a classic unchecked-return-value flaw: the code checks that the HTTP transaction completed ({ok, ...}) but does not verify the semantic success of the operation via the StatusCode field. The attack surface is the JWKS endpoint URL configured in RabbitMQ's OAuth2 configuration, which is contacted periodically or on cache miss to refresh signing keys.

Exploitation Scenarios

The attack chain, inferred from the vulnerability class (CWE-252 unchecked return value causing resource destruction), proceeds as follows:

1. Reconnaissance/Target Identification: The attacker identifies a RabbitMQ deployment configured with the OAuth2/JWT authentication backend. RabbitMQ Management interfaces are commonly exposed on port 15672 (HTTP) and 15671 (HTTPS). The attacker determines the OAuth2 provider's JWKS endpoint URL, which may be exposed in configuration files, error messages, or by observing network traffic between RabbitMQ and the identity provider. No authentication is required to trigger the underlying flaw if the attacker can influence the JWKS endpoint's response.

2. Triggering the Vulnerability Class: The attacker must cause the JWKS endpoint to return an HTTP error response (4xx or 5xx) with a valid-JSON body that lacks a keys field. This could be achieved through several mechanisms depending on the deployment: (a) compromising or spoofing the OAuth2 provider's JWKS endpoint via network positioning (e.g., DNS spoofing, ARP poisoning, or BGP hijacking) if the connection is not TLS-pinned; (b) exploiting a separate vulnerability in the OAuth2 provider that allows returning crafted error responses; (c) causing the identity provider to return a JSON error body on an error status (many providers return {"error": "..."} with 4xx/5xx status codes, which lacks a keys field); or (d) if the JWKS URL is user-influenced or configurable by a lower-privileged party, pointing it to a malicious endpoint.

3. Payload/Execution Method: The attacker ensures the JWKS endpoint responds with a non-200 status code and a JSON body such as {"error": "temporarily unavailable"} or any valid JSON object without a keys array. When RabbitMQ's uaajwt.erl processes this response, the pattern {ok, {_, _, JwksBody}} matches, and the parsing logic treats the lack of a keys field as an empty key set, purging the cached signing keys.

4. Post-Exploitation Impact: Once the key cache is destroyed, all legitimate OAuth2/JWT authentication attempts fail because RabbitMQ has no signing keys against which to validate JWTs. This causes a persistent authentication denial of service for all users relying on OAuth2/JWT authentication across the entire RabbitMQ cluster. The DoS persists until a successful JWKS refresh occurs (i.e., the endpoint returns a 200 response with a valid keys field). An attacker who can continuously trigger error responses can maintain the denial of service indefinitely. No public PoC or exploit code is available; the attack chain is inferred from the vulnerability class and description.

Impact Assessment

The impact is primarily availability (CVSS 3.1 base score: N/A; vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The vulnerability allows a network-based attacker with no privileges and no user interaction to cause a high-impact denial of service. Confidentiality and integrity are unaffected. The blast radius is the entire RabbitMQ deployment: all OAuth2/JWT-authenticated users are locked out, affecting messaging producers, consumers, and management interface access. In environments where RabbitMQ is a critical message broker for application integration, this can cascade into broader application outages. The attack is amplified because a single attacker action can deny access to all legitimate users. The EPSS score is not yet available from FIRST.org. There is no evidence of active exploitation in the wild or inclusion in CISA KEV.

Detection Guidance

Sigma Rule

title: RabbitMQ JWKS Fetch Failure Leading to Authentication DoS
id: 8a4f1c2e-9b3d-4e5f-a6c7-1d2e3f4a5b6c
status: experimental
description: Detects repeated JWKS fetch failures with non-200 status codes that may indicate exploitation of CVE-2026-67409
author: Threat Intelligence
date: 2026-01-01
logsource:
  product: rabbitmq
  service: auth_backend_oauth2
detection:
  selection:
    EventID: 'jwks_fetch'
    StatusCode:
      - '>=400'
    Body|contains: 'keys'
  condition: selection
falsepositives:
  - Transient OAuth2 provider outages
level: high
tags:
  - attack.t1190
  - cve.2026.67409

YARA Rule

rule CVE_2026_67409_RabbitMQ_JWKS_Unchecked_Status
{
    meta:
        description = "Detects vulnerable RabbitMQ uaajwt.erl pattern ignoring HTTP status code"
        author = "Threat Intelligence"
        date = "2026-01-01"
        cve = "CVE-2026-67409"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-67409"
    strings:
        $erl_pattern = "{ok, {_, _, JwksBody}}" ascii wide
        $file1 = "uaajwt.erl" ascii wide
        $file2 = "uaajwks.erl" ascii wide
        $file3 = "rabbit_oauth2_provider.erl" ascii wide
        $err_body = "\"keys\"" ascii wide
    condition:
        2 of ($file*) and $erl_pattern
}

Suricata IDS Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2026-67409 RabbitMQ JWKS Non-200 Response with JSON Error Body"; flow:to_server,established; http.response_body; content:"keys"; nocase; http.stat_code; content:"!200"; pcre:"/^[45]\d\d/R"; classtype:attempted-dos; reference:cve,CVE-2026-67409; sid:2026674090; rev:1;)

Elastic Detection

sequence by host.id, process.pid with maxspan=5m
  [network where network.direction == "outbound" and url.path != null and process.name == "beam.smp" and url.full : "*jwks*"]
  [http where http.response.status_code >= 400 and http.response.body : "*keys*" and process.name == "beam.smp"]

Splunk SPL Query

index=rabbitmq sourcetype=rabbitmq:oauth2 OR sourcetype=erlang:log
| search ("jwks" OR "JWKS" OR "uaajwt") AND ("status" OR "StatusCode")
| rex field=_raw "(?i)status(?:Code)?[=:\s]+(?<http_status>\d{3})"
| where http_status >= 400
| stats count by host, http_status, jwks_url
| where count > 3

Wazuh OSSEC Rule

<group name="rabbitmq,cve-2026-67409,">
  <rule id="202674091" level="12">
    <decoded_as>json</decoded_as>
    <field name="event">jwks_fetch</field>
    <field name="status_code">\.4\d\d|\.5\d\d</field>
    <description>CVE-2026-67409: RabbitMQ JWKS fetch returned non-200 status code, potential authentication DoS</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="202674092" level="14" frequency="5" timeframe="300">
    <if_matched_sid>202674091</if_matched_sid>
    <description>CVE-2026-67409: Repeated RabbitMQ JWKS fetch failures, likely active exploitation</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate Mitigations:

   • Monitor RabbitMQ OAuth2/JWT authentication logs for JWKS fetch failures with non-200 status codes.
   • Ensure the OAuth2 provider's JWKS endpoint is highly available and returns proper 200 responses with a valid keys field.
   • Use TLS with certificate pinning for the connection between RabbitMQ and the OAuth2 provider's JWKS endpoint to prevent network-based response manipulation.
   • Restrict network access to the JWKS endpoint and monitor for anomalous responses.
   • Consider configuring a fallback authentication mechanism for emergency access if OAuth2 authentication is critical.

2. Patch/Upgrade Steps:

   • Although patch confidence is 0/4, the NVD description states the issue is fixed in RabbitMQ versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.
   • Track vendor advisories for these versions and apply the upgrade when available and validated.
   • Test upgrades in a staging environment before production deployment.

3. Long-Term Hardening:

   • Implement robust error handling in custom RabbitMQ plugins and configurations that validate HTTP response status codes before processing response bodies.
   • Adopt a defense-in-depth approach: monitor, alert, and automate recovery (e.g., automatic JWKS cache refresh on authentication failures).
   • Regularly review OAuth2/JWT integration configurations for security best practices.
   • Subscribe to RabbitMQ security announcements and CVE feeds for timely patch information.

References

• NVD — CVE-2026-67409
• CWE-252: Unchecked Return Value
• RabbitMQ OAuth2 Authentication Backend Documentation
• RabbitMQ Security Advisories
• MITRE ATT&CK T1190 — Exploit Public-Facing Application