The vulnerability lies in RabbitMQ’s key‑fetching logic for OAuth2 JWT authentication. During JWKS retrieval, the httpc module ignores the HTTP response status code and treats all responses equally. When the JWKS endpoint returns a non‑200 status with a valid JSON body that lacks a keys field, the logic destroys all cached signing keys. Consequently, every OAuth2/JWT authentication attempt fails, resulting in a persistent denial of service for all users.

RabbitMQ servers from versions 3.13.0 through 4.3.3, including 4.2.9, 4.1.14, 4.0.23 and 3.13.18, are affected. The issue is specific to the rabbitmq-server product provided by the RabbitMQ vendor.

The CVSS score of 8.2 classifies this as a high‑severity flaw. EPSS data is not available, and it is not listed in the CISA KEV catalog. The likely attack vector is an attacker who can control or spoof the OAuth2 provider’s JWKS endpoint to return a 4xx or 5xx response with an empty keys field. This remote exploitation would destroy the broker’s cached keys and trigger authentication denial for all clients until a successful JWKS refresh occurs. The severity and potential impact warrant urgent remediation.