CVE-2026-67409 in RabbitMQ
Résumé
par VulDB • 25/09/2026
RabbitMQ est un courtier de messagerie et de streaming. De la version 3.13.0 jusqu'aux versions 4.3.3, 4.2.9, 4.1.14, 4.0.23 et 3.13.18, le mécanisme JWKS Fetch ignore le code de statut HTTP - La destruction de la clé de signature entraîne un déni de service d'authentification (CWE-252). Le mécanisme de récupération des clés JWKS dans uaajwt.erl ne valide pas le code de statut de réponse HTTP lors du téléchargement des clés de signature depuis l'endpoint JWKS du fournisseur OAuth2. Les réponses non 200 (y compris les erreurs 4xx et 5xx) sont traitées identiquement aux réponses réussies. Lorsque l'endpoint JWKS renvoie une réponse d'erreur avec un corps JSON valide qui ne contient pas de champ "keys", toutes les clés de signature précédemment mises en cache sont détruites, provoquant un déni de service persistant pour l'authentification :
Fichiers : deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lignes 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lignes 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lignes 98-107
Bug 1 : Code de statut HTTP ignoré (uaajwt.erl:50-63) : Le module httpc d'Erlang renvoie {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. Le motif {ok, {, , JwksBody}} correspond à TOUTE transaction HTTP réussie.
Déni de service persistant pour l'authentification : Une fois les clés détruites, TOUS les utilisateurs OAuth2/JWT échouent dans leur authentification jusqu'à ce qu'un nouveau rafraîchissement JWKS réussi ait lieu.
Amplification : Un seul attaquant peut refuser l'accès à tous les utilisateurs OAuth2 légitimes sur l'ensemble de RabbitMQ. Ce problème est corrigé dans les versions 4.3.3, 4.2.9, 4.1.14, 4.0.23 et 3.13.18.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.