kyos-public/keycloak-cve-2026-18963-huntSuche nach Spuren der Ausnutzung von CVE-2026-18963 (nicht authentifizierte Kontoübernahme in Keycloak) in der Keycloak-Datenbank
Ein psql-Skript, das eine Keycloak-PostgreSQL-Datenbank nach Spuren der Ausnutzung von CVE-2026-18963 durchsucht (Kontoübernahme ohne Authentifizierung über den Reset-Credentials-Ablauf).
Veröffentlicht von KYOS. Wir haben es geschrieben, während wir die von uns betriebenen Keycloak-Installationen gepatcht haben, um zu überprüfen, dass während des Expositionszeitraums niemand übernommen wurde.
CVE-2026-18963 ist ein Fehler im Reset-Credentials-Ablauf von keycloak-services (keycloak#51833). Ein nicht authentifizierter Angreifer kann den Passwort-Reset-Prozess für jeden Benutzer abschließen, ohne den E-Mail-Verifizierungslink anzuklicken, und anschließend ein neues Passwort für das Konto setzen. Keine Benutzerinteraktion ist erforderlich.
Schweregrad: Kritisch, CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), laut Red Hat und NVD. Ursache ist eine unzureichende Zustandsvalidierung im Authentifizierungsablauf, behoben in keycloak#51844.
| Stream | Behoben in |
|---|---|
| 26.7.x | 26.7.2 (Versionshinweise) |
| 26.6.x | 26.6.6 |
| 26.4.x (LTS) | 26.4.15 |
| 26.8 | 26.8.0 |
Alles unterhalb dieser Versionen in den unterstützten Streams ist verwundbar. Nicht mehr unterstützte Versionen (26.5.x, 26.3 und älter) erhalten keinen Fix: Gehen Sie von einer Gefährdung aus und aktualisieren Sie auf einen unterstützten Stream. Red Hat listet das Legacy-RH-SSO 7 als nicht betroffen; der Red Hat Build von Keycloak 26.4/26.6 ist in 26.4.15-1 / 26.6.6-1 behoben.
Das Deaktivieren des Self-Service-Passwort-Resets entfernt den verwundbaren Einstiegspunkt: Admin-Konsole > Realm-Einstellungen > Login > „Passwort vergessen“ aus, für jedes Realm. Über die Admin-API: PUT /admin/realms/{realm} mit {"resetPasswordAllowed": false}.
Dies blockiert den Endpunkt login-actions/reset-credentials, verhindert aber auch, dass legitime Benutzer ihr eigenes Passwort zurücksetzen können. Betrachten Sie dies daher nur als Übergangslösung, bis Sie aktualisieren. Beachten Sie, dass Red Hat für diese CVE keine unterstützte Abhilfemaßnahme listet; Patchen ist die einzige echte Lösung.
cve-2026-18963-keycloak-hunt.sql führt vier schreibgeschützte Abfragen aus:
| Abfrage | Was sie findet |
|---|---|
| Q0 | Ob das Realm überhaupt Login-/Admin-Events speichert und deren TTL. Wenn Events deaktiviert oder abgelaufen sind, beweisen leere Ergebnisse in Q2/Q3 nichts. |
| Q1 | Jede Passwort-Anmeldeinformation, die innerhalb des Expositionszeitraums gesetzt wurde (credential.created_date). Das ist die Übernahme selbst und funktioniert auch, wenn die Event-Protokollierung deaktiviert war. |
| Q2 | Reset-/Credential-Login-Events, die jeden abgeschlossenen Reset ohne SEND_RESET_PASSWORD in den vorherigen 24 Stunden markieren (no_email_before = t). Dieses Flag ist die CVE-Signatur: Der Angreifer hat die E-Mail nie ausgelöst. |
| Q3 | Admin-API-Credential-Resets und Execute-Actions-Operationen, um die Admin-gesteuerte Route auszuschließen. |
# defaults: realm 'master', window since 2026-06-01
psql -U keycloak -d keycloak -f cve-2026-18963-keycloak-hunt.sql
# explicit realm and window (run once per realm, quote values exactly like this)
psql -U keycloak -d keycloak \
-v realm="'myrealm'" -v since="'2026-05-01'" \
-f cve-2026-18963-keycloak-hunt.sql
Setzen Sie since auf einen Zeitpunkt kurz bevor Ihre verwundbare Version live ging. Auf Kubernetes:
kubectl exec -it my-postgres-pod -- \
psql -U keycloak -d keycloak -v realm="'myrealm'" -v since="'2026-05-01'" \
-f - < cve-2026-18963-keycloak-hunt.sql
Zeilen in Q1 sind nicht automatisch Kompromittierungen. Gleichen Sie jede mit einer bekannten legitimen Ursache ab (Self-Service-Reset, Helpdesk-Aktion, neue Registrierung) und behandeln Sie alles Ungeklärte als Kandidat für eine Übernahme.
Q2-Zeilen mit no_email_before = t bei RESET_PASSWORD, UPDATE_CREDENTIAL oder UPDATE_PASSWORD sind der stärkste Indikator dafür, dass diese CVE ausgenutzt wurde. Korrelieren Sie die Spalte ip_address mit Ihren Zugriffsprotokollen.
Prüfen Sie zuerst Q0: Login-Events laufen ab (events_expiration) und können vollständig deaktiviert sein. Q1 läuft nicht ab und ist daher die zuverlässigste Prüfung.
MIT, siehe LICENSE. Bereitgestellt wie besehen, ohne Gewährleistung.