Keycloak CVE-2026-18963: Kritische Passwort-Reset-Lücke ermöglicht Account-Übernahme
Eine kritische Schwachstelle im Open-Source-Identity-Server Keycloak erlaubte unauthentifizierten Angreifern die vollständige Übernahme beliebiger Benutzerkonten, einschließlich Admin-Zugängen. Der Fehler steckte in der Zustandsprüfung des Passwort-Reset-Ablaufs. Wir zeigen, welche Versionen betroffen sind, wie das Update läuft und welche Sofortmaßnahme greift, wenn ein Patch noch aussteht.
Am 18. August 2026 hat Red Hat gemeinsam mit dem Keycloak-Projekt Patches für eine kritische Sicherheitslücke veröffentlicht, die das komplette Identitätsmanagement vieler Unternehmen betreffen kann. Die Lücke mit der Kennung CVE-2026-18963 erhielt einen CVSS-Score von 9,1 und erlaubte es einem nicht authentifizierten Angreifer, ohne jede Nutzerinteraktion die vollständige Kontrolle über beliebige Benutzerkonten zu erlangen, einschließlich administrativer Zugänge.
Was ist passiert?
Keycloak ist einer der meistgenutzten Open-Source-Server für Identity- und Access-Management (IAM). Er wird von Unternehmen weltweit als zentrale Login- und Single-Sign-On-Lösung eingesetzt, oft im Zusammenspiel mit internen Anwendungen, Kundenportalen oder als Identity-Provider für weitere Dienste. Die Schwachstelle liegt konkret im sogenannten Reset-Credentials-Flow, also dem Ablauf, den Keycloak startet, wenn ein Nutzer sein Passwort zurücksetzen möchte.
Red Hat bezeichnet die Ursache als "unsachgemäße Zustandsvalidierung innerhalb des Reset-Credentials-Authentifizierungsflows". Normalerweise sendet Keycloak dabei einen sogenannten Action-Token per E-Mail, den der Nutzer anklicken muss, bevor der eigentliche Passwort-Reset erfolgt. Bei der entdeckten Lücke konnte ein Angreifer diesen Schritt komplett umgehen: Eine speziell präparierte Anfrage an den Reset-Credentials-Endpunkt ließ die Authentifizierungssitzung direkt in die Passwort-Update-Phase springen, ohne dass der Action-Token jemals benötigt oder überprüft wurde.
Das Ergebnis: Ein Angreifer, der lediglich den Benutzernamen oder die E-Mail-Adresse eines Zielkontos kennt, konnte dessen Passwort zurücksetzen und sich anschließend anmelden, ganz ohne Zugriff auf das E-Mail-Postfach des Opfers und ohne jede vorherige Authentifizierung am System.
Betroffene Systeme und Versionen
Die Lücke betrifft sowohl das quelloffene Upstream-Projekt Keycloak als auch die kommerzielle Variante Red Hat build of Keycloak (RHBK). Folgende Versionen sind konkret betroffen beziehungsweise ab welcher Version die Lücke geschlossen ist:
| Produkt | Betroffen bis | Fix ab Version | Erratum |
|---|---|---|---|
| Upstream Keycloak | vor 26.7.2 | 26.7.2 | GitHub-Release 19.08.2026 |
| Red Hat build of Keycloak 26.4 | vor 26.4.15 | Operator-Bundle 26.4.15-1 | RHSA-2026:56519 / 56520 |
| Red Hat build of Keycloak 26.6 | vor 26.6.6 | Operator-Bundle 26.6.6-1 | RHSA-2026:56523 / 56524 |
| keycloak-rhel9 Container-Images | vor 26.4-23 bzw. 26.6-12 | 26.4-23 / 26.6-12 | siehe oben |
Der ursprüngliche CVE-Eintrag listete zusätzlich Red Hat Single Sign-On 7 und das Red Hat JBoss Enterprise Application Platform Expansion Pack. Eine spätere Revision hat diese Angaben eingeschränkt, laut aktuellem NVD-Eintrag ist der endgültige Status für beide Produkte nicht abschließend geklärt. Wer eines dieser Produkte im Einsatz hat, sollte die Herstellerangaben direkt bei Red Hat prüfen, statt sich allein auf die NVD-Zusammenfassung zu verlassen.
Gibt es aktive Angriffe?
Nach aktuellem Kenntnisstand (Stand 24. August 2026) liegen keine Hinweise auf eine aktive Ausnutzung der Lücke vor, und es wurde bislang kein öffentlich verfügbarer Proof-of-Concept-Exploit identifiziert. Das sollte Admins aber nicht zur Verzögerung des Updates verleiten: Sobald technische Details öffentlich kursieren, sind Reverse-Engineering und Exploit-Entwicklung für einen so klar beschriebenen Logikfehler erfahrungsgemäß eine Frage von Tagen, nicht Wochen.
Sicherheitsforscher Enzo Mongin, der im Juli eine verwandte Keycloak-Zugriffskontroll-Lücke offengelegt hatte, weist zusätzlich auf ein grundsätzliches Risiko hin: Wer eine Grenze am Identity-Server überwindet, landet damit potenziell in allen Systemen, die hinter diesem Server hängen. Bei einem zentralen SSO-Server heißt das im Zweifel: Übernahme eines Kontos kann Zugriff auf mehrere angebundene Anwendungen gleichzeitig bedeuten.
Was Admins jetzt prüfen sollten
- Versionsstand aller produktiven Keycloak- und RHBK-Instanzen ermitteln (Admin-Konsole oder Server-Info-Endpunkt)
- Bei Betrieb via Container: verwendete Image-Tags gegen die Fix-Versionen 26.4-23 bzw. 26.6-12 abgleichen
- Update-Fenster für alle betroffenen Realms einplanen, nicht nur für die Produktivumgebung
- Nach dem Update kontrollieren, ob alle Realms tatsächlich die neue Version nutzen, insbesondere bei Multi-Realm- oder Multi-Tenant-Betrieb
- Audit-Logs der letzten Wochen auf ungewöhnlich viele Passwort-Reset-Anfragen prüfen, besonders für Administrator-Konten
- Bestehende Sitzungen nach dem Update prüfen und im Zweifel invalidieren
- Falls ein sofortiges Update nicht möglich ist: befristete Mitigation aktivieren (siehe unten)
- Nach dem Patch testen, ob der reguläre Passwort-Reset-Ablauf für normale Nutzer weiterhin funktioniert
Sofortmaßnahme, wenn ein Update nicht sofort möglich ist
Für Umgebungen, die nicht kurzfristig aktualisiert werden können, hat Red Hat eine temporäre Abhilfe veröffentlicht: Die Funktion "Passwort vergessen" lässt sich pro Realm deaktivieren. In der RHBK-Administrationskonsole findet sich die Einstellung unter Realm settings, dann Login, dann Forgot password. Wichtig dabei: Diese Einstellung muss manuell für jeden einzelnen Realm gesetzt werden, es gibt keine globale Schalterlösung. Wer mehrere Realms betreibt, etwa für unterschiedliche Mandanten oder Anwendungen, muss die Deaktivierung entsprechend für jeden Realm einzeln vornehmen und dokumentieren.
Diese Mitigation ist ausdrücklich als Übergangslösung gedacht. Sie schränkt die Selbstbedienungsfunktion für Nutzer ein und sollte so schnell wie möglich durch das eigentliche Update ersetzt werden.
Einordnung für kleine und mittlere Unternehmen
Keycloak wird häufig gerade in kleineren und mittelständischen Unternehmen als kostenlose Alternative zu kommerziellen IAM-Lösungen eingesetzt, etwa zur zentralen Anmeldung für interne Tools, Kundenportale oder als Identity-Provider bei Synology-NAS-Systemen. Genau diese zentrale Rolle macht eine Lücke wie CVE-2026-18963 besonders kritisch: Ein einziger erfolgreicher Angriff auf den Identity-Server kann sich auf alle angebundenen Dienste auswirken. Wer Keycloak selbst betreibt, sollte das Update nicht als "nice to have", sondern als Pflichtaufgabe mit hoher Priorität einstufen, auch wenn aktuell keine aktive Ausnutzung bekannt ist.
Passende Anleitungen auf S-EDV
- Keycloak auf dem Synology NAS installieren: SSO und zentrale Logins mit OIDC und SAML
- Single Sign-On für den Self-Hosted-Stack: Authentik vs. Authelia mit Traefik Forward-Auth absichern
