CVE-2026-67409: RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS

Published Sep 25, 2026
·
Updated

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.

Affected Software

1 affected component
RabbitMQ RabbitMQ>=3.13.0<=3.13.17, >=4.0.0<=4.0.22, >=4.1.0<=4.1.13, >=4.2.0<=4.2.8, >=4.3.0<=4.3.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade RabbitMQ to a version that resolves this vulnerability.

    Fixed in 4.3.3
  2. Upgrade

    Upgrade RabbitMQ to a version that resolves this vulnerability.

    Fixed in 4.2.9
  3. Upgrade

    Upgrade RabbitMQ to a version that resolves this vulnerability.

    Fixed in 4.1.14
  4. Upgrade

    Upgrade RabbitMQ to a version that resolves this vulnerability.

    Fixed in 4.0.23
  5. Upgrade

    Upgrade RabbitMQ to a version that resolves this vulnerability.

    Fixed in 3.13.18

Event History

Sep 25, 2026
CVE Published
via MITRE·04:18 PM
Data Sourced
via MITRE·04:18 PM
DescriptionWeakness
Data Sourced
via NVD·05:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203