CVE-2026-67409 in RabbitMQ
Zusammenfassung
von VulDB • 25.09.2026
RabbitMQ ist ein Messaging- und Streaming-Broker. Von der Version 3.13.0 bis zu den Versionen 4.3.3, 4.2.9, 4.1.14, 4.0.23 und 3.13.18 wird beim JWKS-Fetch (JWKS Fetch) der HTTP-Antwortstatuscode ignoriert – die Zerstörung des Signierschlüssels verursacht einen Authentifizierungs-DoS (CWE-252). Der Mechanismus zum Abrufen von JWKeys in uaajwt.erl validiert den HTTP-Antwortstatuscode nicht, wenn Signierschlüssel vom JWKS-Endpunkt des OAuth2-Anbieters heruntergeladen werden. Antworten mit einem Status ungleich 200 (einschließlich Fehler der Klassen 4xx und 5xx) werden identisch wie erfolgreiche Antworten verarbeitet. Wenn das JWKS-Endpunkt eine Fehlerantwort mit einem gültigen JSON-Körper zurückgibt, der kein keys-Feld enthält, werden alle zuvor zwischengespeicherten Signierschlüssel zerstört, was zu einer anhaltenden Authentifizierungsverweigerung führt:
Dateien: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, Zeilen 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, Zeilen 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, Zeilen 98-107
Fehler 1: HTTP-Statuscode wird ignoriert (uaajwt.erl:50-63): Das Erlang httpc-Modul gibt {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}} zurück. Das Muster {ok, {_, _, JwksBody}} passt auf JEDE erfolgreiche HTTP-Transaktion.
Anhaltender Authentifizierungs-DoS: Sobald die Schlüssel zerstört sind, schlägt ALLE OAuth2/JWT-Authentifizierung für alle Benutzer fehl, bis eine neue erfolgreiche JWKS-Aktualisierung stattfindet.
Verstärkungseffekt (Amplification): Ein einzelner Angreifer kann den Zugriff aller legitimen OAuth2-Benutzer über das gesamte RabbitMQ hinweg verweigern. Dieses Problem wurde in den Versionen 4.3.3, 4.2.9, 4.1.14, 4.0.23 und 3.13.18 behoben.
Once again VulDB remains the best source for vulnerability data.