Die Meldung klingt zunächst nach einem eng begrenzten Anwendungsfehler: Keycloak hatte einen kritischen Fehler im Passwort-Reset. Ein Angreifer konnte den Nachweis über die Reset-Mail überspringen und für ein fremdes Konto ein neues Passwort setzen. Patch einspielen, Ticket schließen.
Keycloak wird häufig gerade deshalb eingesetzt, weil eine Organisation Identitäten, Gruppen und Rollen für mehrere Dienste gemeinsam verwalten will. Daran können neben Webanwendungen auch Kubernetes, OpenStack oder weitere Teile einer Cloud-Plattform hängen.
Wie schwer ein solcher Fehler wiegt, hängt deshalb auch davon ab, welche Systeme dem betroffenen Identity Provider vertrauen. Der Passwort-Reset verändert den Identitätsnachweis, auf den sie ihre Zugriffsentscheidungen stützen.
Der Fehler
CVE-2026-18963 steckt im reset-credentials-Flow von Keycloak. Laut Red Hat ließ sich der Ablauf so manipulieren, dass die Authentifizierungssitzung direkt in die Passwortänderung wechselte. Der Action Token aus der Reset-Mail war nicht mehr nötig. Damit entfiel genau der Nachweis, auf dem dieser Recovery-Pfad beruhte: der Zugriff auf das hinterlegte Postfach.[1]
Ein nicht authentifizierter Angreifer konnte dadurch neue Zugangsdaten für beliebige Konten setzen, auch ohne Mitwirkung des betroffenen Benutzers. Red Hat bewertet die Schwachstelle als kritisch. Upstream wurde sie mit dem am 19. August 2026 veröffentlichten Keycloak 26.7.2 behoben.[2] Wenn ein Update nicht sofort möglich ist, empfiehlt Red Hat, „Forgot password“ vorübergehend in allen Realms abzuschalten.[1]
Das Advisory belegt keine aktive Angriffswelle. Seine technische Beschreibung reicht aus, um die Dringlichkeit zu begründen.
Mehrere Dienste vertrauen demselben Identitätsnachweis
Keycloak übernimmt zentrale Aufgaben, die sonst jede Anwendung selbst lösen müsste. Benutzer melden sich am Identity Provider an; die angebundenen Dienste übernehmen diese Authentifizierungsentscheidung und prüfen anschließend ihre eigenen Berechtigungen. LDAP und Active Directory lassen sich einbinden, weitere Identity Provider über OpenID Connect oder SAML föderieren. Rollen, Gruppen und andere Claims landen in den ausgestellten Tokens.[7]
Das spart lokale Konten und selbst gebaute Loginlogik und schafft einen gemeinsamen Ort für Richtlinien und Sitzungen. Zugleich konzentriert es das Vertrauen auf einen Dienst.
Das betrifft nicht nur die Anmeldung. In Keycloak werden externe Identitäten lokalen Konten zugeordnet, Gruppen verwaltet und Tokens für angebundene Clients konfiguriert. Welche Tokens ein Zielsystem tatsächlich akzeptiert, bestimmt auch dessen eigene Konfiguration. Ein Fehler im Recovery-Flow ändert also nicht bloß eine Zeichenfolge in einer Benutzerdatenbank. Er ändert, wer sich künftig als diese Identität ausweisen kann.
Das passt zu einer älteren Beobachtung: Der gefährlichste Angriff ist oft schon eingeloggt. Hier muss der Angreifer nicht einmal das bisherige Passwort kennen. Der fehlerhafte Recovery-Flow verschafft ihm ein neues.
Wenn aus dem Reset eine Anmeldung wird
Red Hat beschreibt als Auswirkung die vollständige Übernahme beliebiger Konten. Für die genaue Wirkung bleibt trotzdem der konfigurierte Authentifizierungsflow entscheidend. Wenn das neue Passwort für die Anmeldung genügt, kann sich der Angreifer regulär bei Keycloak anmelden. Keycloak stellt dann ein signiertes Token aus, das die angeschlossene Anwendung anhand von Aussteller, Zielgruppe, Signatur, Laufzeit und Claims prüft.[1]
Wo das Passwort als Login-Nachweis genügt, braucht der Angreifer kein bestehendes Token zu stehlen. Nach dem unberechtigten Reset und einer erfolgreichen Anmeldung stellt der vorgesehene Identity Provider selbst neue gültige Tokens aus.
Verlangt ein Realm zusätzlich einen unabhängigen zweiten Faktor, belegt der öffentlich beschriebene Passwort-Reset nicht automatisch dessen Umgehung. Der unautorisierte Credential-Wechsel bleibt kritisch; ob daraus unmittelbar eine vollständige Sitzung wird, hängt vom restlichen Flow ab.
Das nachgelagerte System kann diesen Fehler nicht aus der Signatur lesen. Es sieht eine technisch korrekte Aussage seiner Vertrauensquelle. Der Fehler liegt davor, im Übergang von „Passwort vergessen“ zu „darf neue Zugangsdaten setzen“.
Recovery ist damit keine Komfortfunktion am Rand des Logins. Es ist eine privilegierte Änderung an der Identität.
Die Reichweite hängt an den Berechtigungen
Aus einem übernommenen Keycloak-Konto folgt nicht automatisch die Übernahme aller angeschlossenen Systeme. Entscheidend ist die konkrete Konfiguration:
- In welchem Realm liegt das Konto?
- Welche Clients vertrauen diesem Realm?
- Welche Gruppen und Rollen stehen in den Tokens?
- Wie übersetzen die Zielsysteme diese Claims in lokale Rechte?
- Handelt es sich um einen normalen Benutzer oder um einen Plattformadministrator?
- Welche Sitzungen und Offline-Tokens bleiben nach dem Passwortwechsel gültig?
Ein gewöhnliches Konto bleibt zunächst ein gewöhnliches Konto. Wenn dieselbe Identität mehrere interne Anwendungen erreicht, wächst der Schaden. Bei einem administrativen Konto können aus den Claims Rechte auf Plattformen entstehen, die Keycloak eigentlich zentral absichern sollte.
Die Schwachstelle setzt diese Berechtigungen nicht außer Kraft. Sie kann dem Angreifer aber die Identität verschaffen, der sie bereits zugewiesen sind.
Wenn Identität bis in die Infrastruktur reicht
Kubernetes verwaltet normale Benutzer nicht als eigene API-Objekte. Der API-Server kann stattdessen ID-Tokens eines externen OpenID-Connect-Providers prüfen. Der Benutzer authentifiziert sich beim Identity Provider und legt das ID-Token gegenüber Kubernetes vor. Kubernetes prüft das Token und entscheidet anschließend per Autorisierung, ob die bezeichnete Identität die gewünschte Aktion ausführen darf.[3]
Diese Trennung bleibt wichtig. Keycloak authentifiziert; bei Verwendung von Kubernetes-RBAC bestimmen dessen Bindings die erlaubten Aktionen. Ein kompromittiertes Keycloak-Konto wird nicht automatisch zum Cluster-Admin. Treffen seine Gruppen-Claims aber auf privilegierte RoleBindings oder ClusterRoleBindings, erhält der Angreifer diese Rechte über die vorgesehene Vertrauenskette. Dafür braucht er keinen Kubernetes-Exploit.
Bei OpenStack ist das Prinzip ähnlich. Keystone unterstützt föderierte Identitäten und nennt Keycloak ausdrücklich als üblichen externen Identity Provider. Keystone ordnet die externe Identität über Mappings lokalen Gruppen oder Projekten zu und stellt eigene Tokens für OpenStack-Dienste aus.[4]
Je nach Mapping kann dieselbe Identität damit Projekte, virtuelle Maschinen, Images, Netzwerke oder Storage erreichen. Keycloak legt diese OpenStack-Rechte nicht allein fest. Es liefert aber den Identitätsnachweis, mit dem Keystone die weitere Autorisierung beginnt.
SCS zeigt, wie weit das gehen kann
Beim Sovereign Cloud Stack ist Keycloak kein zufälliges Integrationsbeispiel. Schon das erste Architekturbild der offiziellen SCS-Dokumentation führt eine eigene IAM Layer und nennt dort Keycloak.[8]
Ein dort veröffentlichter Dokumentationsvorschlag beschreibt Keycloak-zu-Keycloak-Föderation zwischen getrennten SCS-Domänen.[9] Ein weiterer Federation-Entwurf verbindet Horizon, Keystone und Keycloak. Für das darin beschriebene Testbed kommt OpenID Connect beim WebSSO zum Einsatz. Die OpenStack-CLI holt zunächst ein Token von Keycloak; die Keystone-Anbindung validiert es anschließend.[5]
Bereits SCS-Arbeitsunterlagen vom Dezember 2023 behandeln Keycloak als Dienst der Management- und Infrastrukturebene. Sie diskutieren Deployment, Datenbank, Hochverfügbarkeit, Monitoring und die Konfiguration von Realms, Recovery, OIDC-Clients und 2FA.[6] Das belegt die architektonische Rolle, nicht den heutigen Konfigurations- oder Patchstand einzelner SCS-Installationen.
Das ist keine Kritik am Sovereign Cloud Stack. Offene Standards, nachvollziehbare Komponenten und ein anbieterneutraler Aufbau sind sinnvoll. Die Architektur zeigt aber sehr deutlich, welche Rolle das IAM spielt. Keycloak bestätigt die Identität; Keystone, Kubernetes-RBAC und lokale Policies legen fest, was diese Identität darf. Fällt der erste Teil falsch aus, arbeiten die nachgelagerten Kontrollen mit einer falschen Ausgangslage.
Souverän betrieben heißt nicht automatisch sicher betrieben. Wer die Plattform selbst betreibt, muss auch ihr IAM absichern. Beim Hyperscaler entfällt diese Verantwortung ebenfalls nicht; dort ist sie zwischen Anbieter und Kunde anders verteilt.
Recovery gehört zur Control Plane
Ein normaler Login prüft, ob ein Benutzer den vereinbarten Nachweis erbringen kann. Recovery entscheidet, wer diesen Nachweis ersetzen darf. Account Linking entscheidet, welche externe Identität künftig als dasselbe Konto gilt. Rollen- und Gruppen-Mappings geben dieser Identität organisatorische Bedeutung. Der Session-Widerruf entscheidet schließlich, welche älteren Vertrauensnachweise weiterleben.
Diese Funktionen verändern, welchen Identitätsnachweisen das System vertraut. Ihre Zustandsübergänge und Besitznachweise verdienen dieselbe Aufmerksamkeit wie administrative APIs.
Die Release-Liste von Keycloak 26.7.2 passt unangenehm gut dazu. Neben CVE-2026-18963 enthält sie weitere Schwachstellen bei Account Linking, feingranularen Admin-Berechtigungen und der Behandlung rotierter Client-Secrets.[2] Das sind verschiedene Fehler mit verschiedenen Voraussetzungen. Sie liegen aber alle abseits des gewöhnlichen Passwortvergleichs, dort, wo Identitäten verbunden, verwaltet oder verändert werden.
Was Betreiber jetzt prüfen sollten
Betroffene Installationen brauchen eine korrigierte Version: Upstream enthält 26.7.2 den Fix; bei Herstellerpaketen ist der jeweilige Advisory- und Paketstand maßgeblich. Falls das Update kurzfristig nicht möglich ist, nennt Red Hat als Zwischenlösung: „Forgot password“ in allen Realms deaktivieren.[1]
Danach reicht ein grünes Patch-Ticket nicht. Betreiber sollten klären:
- welche Realms, Clients, Anwendungen, Cluster und Cloud-Dienste der Instanz vertrauen;
- ob privilegierte Konten Self-Service-Recovery verwenden dürfen;
- welche Keycloak-Gruppen auf Kubernetes-RBAC, Keystone-Gruppen, Projekte oder administrative Rollen abgebildet werden;
- ob Passwort-Reset, Credential Update, Account Linking, neue Authenticatoren und Rollenänderungen zentral protokolliert und korreliert werden;
- welche Sitzungen, Offline-Tokens und nachgelagerten Tokens nach einer Credential-Änderung gültig bleiben;
- ob ein unabhängiger Break-glass-Zugang existiert und tatsächlich funktioniert.
Tests sollten deshalb auch unerlaubte Zustandswechsel und den Widerruf von Berechtigungen abdecken, statt nur erfolgreiche Logins zu prüfen. Der konkrete Reset-Fehler betraf die fehlende Zustandsvalidierung im Recovery-Flow. Account Linking, Rollenänderungen und Secret-Rotation brauchen jeweils eigene Prüfungen; sie sind keine weiteren Stufen desselben Fehlers.
Zentrales IAM bleibt trotzdem richtig
Die Alternative zu zentralem IAM ist selten elegante Dezentralität. Meist sind es lokale Konten, unterschiedliche Richtlinien, vergessene Zugänge und ein Offboarding, bei dem niemand mehr sicher weiß, was noch offen ist. Wildwuchs verteilt nicht nur das Risiko. Er verteilt auch die Ahnungslosigkeit.
Zentralisierung bleibt sinnvoll, wenn die Risikobewertung ihre Reichweite berücksichtigt. Je mehr Systeme einem Identity Provider vertrauen, desto weniger darf dessen Recovery wie eine nebensächliche Login-Funktion behandelt werden. Neben dem CVSS-Wert zählt, welche Identitäten betroffen sind und welche Rechte die Zielsysteme ihnen einräumen.
Bei einer einzelnen Anwendung ist ein kaputter Passwort-Reset ein schwerer Anwendungsfehler. Bei Keycloak kann derselbe Mechanismus eine Organisation, mehrere Anwendungen oder eine föderierte Plattform betreffen. Die beschriebenen SCS-Integrationen zeigen, wie diese Vertrauenskette bis in die Cloud-Infrastruktur reichen kann.
„Nur ein Passwort-Reset“ ist dafür eine bemerkenswert schlechte Beschreibung.
Quellen
- Red Hat: CVE-2026-18963
- Keycloak 26.7.2 released
- Kubernetes: Authenticating
- OpenStack Keystone: Introduction to Federation
- Sovereign Cloud Stack: Keystone-Keycloak Federation Draft
- Sovereign Cloud Stack: Keycloak-Kubernetes IAM notes
- Keycloak Server Administration Guide
- Sovereign Cloud Stack: Architectural Overview
- SCS: Keycloak-to-Keycloak Federation