1. Oktober 2026 · Security-Advisory · Schwachstellenmanagement · IT-Sicherheit · Zero Trust

Keycloak-Sicherheitsupdate: auf 26.7.5 oder neuer aktualisieren

Keycloak 26.7.4 und 26.7.5 schließen eine Reihe von Schwachstellen, darunter eine Rechteausweitung über die Impersonation-Rolle. Ziel: 26.7.5 oder neuer.

Das Keycloak-Projekt hat in kurzem Abstand zwei Wartungsreleases mit Sicherheitskorrekturen veröffentlicht. 26.7.4 (16. September) schließt die sechs hier beschriebenen Lücken, 26.7.5 (30. September) weitere: Seine Release-Notes führen 14 Sicherheitskorrekturen auf, vier davon in Abhängigkeiten. Am 1. Oktober folgte zudem 26.8.0. Das Ziel für Betreiber ist deshalb 26.7.5 oder neuer. Eine der Lücken aus 26.7.4 erlaubt es einem Konto mit eingeschränkten Verwaltungsrechten, sich als Realm-Administrator auszugeben.

Dieser Beitrag richtet sich an Organisationen, die Keycloak selbst betreiben – als zentrale Anmeldung für Mitarbeitende, für Kundenportale oder für Fachanwendungen. Er ordnet die sechs Schwachstellen aus 26.7.4 ein und beschreibt, was vor und nach dem Update zu tun ist.

Warum ein Identitätsanbieter besondere Aufmerksamkeit verdient

Ein Identitätsanbieter (IdP) ist kein Dienst unter vielen. Er stellt die Token aus, denen alle angebundenen Anwendungen vertrauen. Wer den IdP kontrolliert, muss keine Anwendung einzeln angreifen: Er kann sich bei jeder davon anmelden, als wer er möchte, und er kann Anmeldungen so verändern, dass es niemandem auffällt.

In Sicherheitsarchitekturen wird ein solches System deshalb der höchsten Schutzstufe zugeordnet. Microsoft etwa rechnet zentrale Identitätssysteme in seinem Enterprise Access Model zur Steuerungsebene, die aus dem früheren „Tier 0“ hervorgegangen ist. Ein IdP ist damit vergleichbar kritisch wie Domänencontroller. Daraus folgen drei praktische Regeln: Updates werden dort nicht aufgeschoben, administrative Rechte werden dort besonders knapp vergeben, und Verwaltungszugänge sind dort nicht aus dem Internet erreichbar. Eine Schwachstelle, die in einer Fachanwendung „nur“ eine Rechteausweitung wäre, ist im IdP eine Rechteausweitung für alles, was dahinter hängt.

Die sechs Schwachstellen aus 26.7.4

Die Einstufungen stammen aus den Issues des Projekts und der GitHub Advisory Database.

CVE-2026-17526 – Rechteausweitung über die Impersonation-Rolle (hoch, CVSS 7.2). Ein Benutzer mit der Rolle „impersonation“ kann einen Realm-Administrator imitieren und erhält damit nach der Beschreibung im Advisory die volle administrative Kontrolle über den Realm – einschließlich der Verwaltung von Benutzern, Clients und Rollen. Das ist die Lücke mit dem größten Hebel, weil sie eine bewusst eingeschränkte Rolle in eine unbeschränkte verwandelt.

CVE-2026-74909 – Umgehung des Policy Enforcers (hoch, CVSS 8.1). Der Policy Enforcer normalisiert Pfade mit bestimmten kodierten Zeichen nicht korrekt, etwa ein prozentkodiertes Semikolon. Ein angemeldeter Benutzer kann dadurch eine weniger strenge Richtlinie auslösen als vorgesehen und auf geschützte Endpunkte zugreifen. Das Projekt bezeichnet die Korrektur ausdrücklich als Nachbesserung eines unvollständigen früheren Fixes. Relevant ist das für Anwendungen, die ihre Zugriffsregeln über den Keycloak Policy Enforcer durchsetzen.

CVE-2026-90997 – Wiederverwendung von Einmal-Artefakten (hoch). Betroffen ist der zustandslose Betriebsmodus mit MySQL oder MariaDB. Wegen einer abweichenden Zählweise betroffener Datenbankzeilen erkennt der Replay-Schutz bereits verwendete Artefakte nicht. Genannt werden JWT-Client-Assertions, DPoP-Nachweise und nicht wiederverwendbare TOTP-Codes: Wer ein solches Artefakt abfängt, kann es am Token-Endpunkt oder im Anmeldeablauf erneut verwenden. Der Widerruf von Token ist laut Issue nicht betroffen.

CVE-2026-79651 – Denial of Service über Sprach-Tags (hoch, CVSS 7.5). Die Lokalisierungs-Endpunkte übernehmen beliebige Sprach-Tags aus nicht angemeldeten Anfragen in einen unbegrenzten Speicher-Cache. Viele verschiedene Tags genügen, um den Server zum Absturz zu bringen.

CVE-2026-18212 – Speicherleck im SAML-Redirect-Binding (CVSS 7.5 in der GitHub Advisory Database, im Projekt-Issue als „medium“ markiert). Nativer Speicher wird bei der Verarbeitung von SAML-Anfragen nicht freigegeben. Wiederholte fehlerhafte Anfragen ohne Anmeldung erschöpfen den Speicher, bis das Betriebssystem den Prozess beendet.

CVE-2026-19607 – Kontosperrung über Benutzernamen-Kollision (mittel, CVSS 5.3). Im Ablauf der ersten Anmeldung über einen externen Identitätsanbieter kann ein Angreifer einen passenden Benutzernamen beim externen Anbieter registrieren und so eine Kollision auslösen, die den legitimen Benutzer aussperrt. Relevant ist das für alle Realms, in denen sich Benutzer über einen externen Identitätsanbieter anmelden – etwa über eine Föderation mit einem Partner oder einen Social Login.

Zwei der sechs Lücken lassen sich ohne Anmeldung ausnutzen, um den Dienst zum Absturz zu bringen. Für einen zentralen Anmeldedienst ist auch ein Ausfall kein Randthema: Steht der IdP, steht alles, was an ihm hängt.

Was jetzt zu tun ist

  • Auf 26.7.5 oder neuer aktualisieren. Das Projekt verweist vor dem Update auf den Migrationsleitfaden mit der vollständigen Liste der Änderungen. Lesen Sie ihn vor dem Update, nicht danach, und testen Sie das Update auf einer Staging-Instanz mit realistischer Konfiguration – insbesondere Identity-Provider-Anbindungen, SAML-Clients und eigene Themes.
  • Den Stand ermitteln. Die Release-Notes nennen keine betroffenen Versionsbereiche. Gehen Sie deshalb davon aus, dass jede Version vor 26.7.4 betroffen sein kann, und prüfen Sie für die Linien 26.4 und 26.6, ob der Hersteller korrigierte Stände bereitstellt.
  • Die Impersonation-Rolle prüfen, und zwar vor dem Update. Die Rolle „impersonation“ ist eine Client-Rolle des eingebauten Clients „realm-management“ in jedem Realm; für realmübergreifende Verwaltung gibt es entsprechende Rollen an den Clients <Realm-Name>-realm im Master-Realm. Stellen Sie fest, welche Benutzer, Gruppen und Composite-Rollen sie direkt oder indirekt enthalten. Die Dokumentation nennt als typischen Zweck den Support: Ein Problem aus Sicht des betroffenen Benutzers nachvollziehen. Prüfen Sie deshalb besonders Helpdesk- und Supportkonten. Jedes Konto mit dieser Rolle konnte sich in betroffenen Versionen zum Realm-Administrator machen.
  • Nach Spuren suchen. Keycloak hält in imitierten Sitzungen die Kennung und den Benutzernamen des imitierenden Kontos als Sitzungsnotiz fest. Prüfen Sie, soweit Sie Admin-Events und Anmeldeereignisse protokollieren, ob Administratorkonten imitiert wurden und ob in diesem Zusammenhang Rollen, Clients oder Identity-Provider-Einstellungen geändert wurden.
  • Die Rolle danach knapp halten. Auch nach dem Update gilt: Wer imitieren darf, darf sich als ein anderer Mensch anmelden. Vergeben Sie die Rolle nur dort, wo sie gebraucht wird, und nutzen Sie die feingranularen Admin-Berechtigungen, um das Imitieren von Administratoren grundsätzlich auszuschließen.
  • Datenbank und Betriebsmodus prüfen. Wenn Sie den zustandslosen Modus mit MySQL oder MariaDB betreiben, betrifft Sie CVE-2026-90997 unmittelbar.

Das Update planen, ohne es aufzuschieben

Ein IdP-Update betrifft jede Anmeldung, und genau deshalb wird es gern verschoben. Der Upgrading-Leitfaden des Projekts gibt die Leitplanken vor. Ab Keycloak 26.6.0 werden Rolling Updates für Patch-Releases unterstützt; ob sie in Ihrer Umgebung möglich sind, beschreibt der Leitfaden zu Rolling Updates. Wer bereits auf 26.7 ist, kann innerhalb dieser Linie gegebenenfalls ohne Unterbrechung aktualisieren; der Wechsel von 26.6 auf 26.7 ist ein Minor-Upgrade und erfordert laut Upgrading Guide einen Stopp.

Der Leitfaden hält außerdem fest, dass zuerst der Server und danach die Adapter aktualisiert werden. Vor jedem Update verlangt der Leitfaden eine Sicherung der Installation – Konfiguration, Themes – und der Datenbank. Der Hintergrund ist wichtig für die Rückfallplanung: Keycloak unterstützt kein Zurückrollen von Datenbankänderungen. Wer zurück muss, stellt die alte Installation und die Datenbank aus der Sicherung wieder her. Diese Sicherung ist also kein Beiwerk, sondern der einzige Rückweg. Legen Sie sie an, bevor Sie beginnen, und prüfen Sie, dass sie sich wiederherstellen lässt.

Die Verwaltung gehört nicht ins Internet

Die Rechteausweitung setzt ein Konto mit Verwaltungsrechten voraus. Je weniger solcher Konten es gibt und je weniger Wege zur Administrationskonsole führen, desto kleiner ist die Angriffsfläche – nicht nur für diese Lücke, sondern für die nächste. Die Anmeldeseiten müssen erreichbar sein, die Administrationskonsole muss es in aller Regel nicht. Verwaltungskonten gehören hinter eine Multi-Faktor-Authentifizierung, und ihre Vergabe gehört in eine regelmäßige Rezertifizierung.

Wie sector7 unterstützt

Wir unterstützen Sie bei Rollen- und Rechtekonzepten, bei der Verwaltung privilegierter Konten und bei sicheren Anmeldeprozessen mit Multi-Faktor-Authentifizierung. Dazu gehören wiederkehrende Schwachstellen-Scans mit priorisierter Behebung über das Patch-Management. Mehr dazu unter Cyber Security.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0