Keycloak: 20 CVE-Fixes an zwei Tagen, und unsere Instanz stand auf 26.7.1

In dieser Woche taucht in Videos und Newslettern zum selbst betriebenen Stack wieder dieselbe Meldung auf: Keycloak habe 14 CVEs gefixt, heute noch patchen statt übers Wochenende. Die Zahl ist korrekt, die Einordnung nicht. Die 14 Fixes gehören zum Release 26.7.5 vom 30. September, das Oktober-Release 26.8.0 vom 1. Oktober bringt 6 weitere. Dazwischen liegt ein Tag, nicht eine Woche. In Summe stehen damit 20 behobene CVEs an zwei aufeinanderfolgenden Tagen: 13 in Keycloak selbst, 7 in Abhängigkeiten. Ein zweiter Befund kommt aus dem eigenen Betrieb: Unsere Keycloak-Instanz steht auf 26.7.1, in dem Versionsbereich, den beide Releases schließen. Der Post ist damit auch eine Aufgabenliste an uns selbst.

Was die beiden Releases wirklich listen

Die Security-fixes-Sektion von 26.7.5 führt 14 Punkte auf: 10 in Keycloak selbst, 4 als Abhängigkeits-Updates (owasp-java-html-sanitizer, freemarker, zweimal bc-fips). 26.8.0 listet sechs CVEs in fünf Punkten: drei in Keycloak (Rolleneskalation über einen IdP-Mapper beim Identity-Brokering, unverifizierte E-Mail-Adressen, die brokerierte Identitäten erben, Gruppen-Claims, die nur dem Namen nach gegen Pfad-Richtlinien geprüft werden), dazu drei Abhängigkeits-CVEs in zwei Paketen: zwei in jackson-databind 2.22.0, einer in netty-codec-http 4.1.136.Final.

Bei den Produkt-Lücken steht in den GitHub-Issues der Vermerk, sie seien aus einem privaten Repository migriert. Die Maintainer haben koordiniert offengelegt, statt einzelne Meldungen nach und nach fallen zu lassen. Die automatischen Meldungen für die Pakete tragen diesen Vermerk nicht. Zwischen 26.7.4 und 26.8.0 liegt ein echtes Sicherheitspaket, kein Wartungsrelease mit ein paar CVEs am Rand.

Die zehn Produkt-Lücken aus 26.7.5 in der Kurzform. Alle zehn Einstufungen stammen von Red Hat und stehen dort auf Status draft, sind also noch nicht abgeschlossen. NVD weicht bei zweien ab: CVE-2026-18211 auf 5,4 statt 4,2, CVE-2026-18217 auf 4,7 statt 3,4.

Dazu die vier Abhängigkeits-Updates in derselben Sektion: owasp-java-html-sanitizer (CVE-2025-66021, XSS), freemarker (CVE-2026-84939, Pfadtraversierung über eine malformed locale), bc-fips zweimal (CVE-2026-8798, CVE-2026-13505). Für CVE-2026-8798 führt Red Hat keinen Eintrag, die Meldung kommt von Bouncy Castle selbst und sitzt in der CPU-Entropiequelle; MITRE listet sie als veröffentlicht, CVSS v4.0 8,7.

Die drei Lücken, die Betreiber kennen sollten

Ein deaktivierter Client, der weiter Token bekommt. CVE-2026-93999 (Moderat, CVSS 4.2 nach Red Hat, Einstufung draft): Ein Client ist im Admin-Interface deaktiviert, alle prüfen die Deaktivierung beim eigentlichen Tausch, nur der Refresh-Pfad nicht. Wer ein älteres Refresh-Token hält, bekommt weiterhin frisch signierte Access-Tokens, in deren aud-Feld der deaktivierte Client steht. Betrifft auch die Refresh-Tokens aus dem Token Exchange; der unmittelbare Austauschpfad lehnt dagegen mit invalid_client ab. Reproduziert ist das auf 26.7.2. Ressourcen-Server, die pro Request online beim Authorization-Server introspectieren, merken davon nichts; die, die JWTs offline gegen die JWKS prüfen, prüfen ein gültig signiertes Token eines Clients, der gar nicht mehr existieren dürfte. Die Reichweite ist an die Rollen des jeweiligen Nutzers gebunden, ein Privilegiengewinn ist das nicht automatisch. Der Punkt gehört trotzdem in jede Aufräum-Routine: Client abschalten war bisher kein sicheres Abschaltsignal.

Lesende Admins sehen Client-Secrets. CVE-2026-89298 (Moderat, 4.9): Über die Client-Registrierungs-API gab ein einfacher GET das vertrauliche Client-Secret im Klartext an Konten mit view-clients-Rolle, also an reine Lesezugriffe. Damit wird ein Leserecht auf die Realm-Verwaltung zum Ausgangspunkt für Hochstufung. Authentifizierung nötig, aber die Schwelle liegt niedriger als bei den meisten vorangegangenen Admin-API-Fehlern. In 26.8.0 steht derselbe Themenkreis zusätzlich als dokumentierte Schwäche („Client GET endpoints return raw client secrets to view-clients role holders") in einer eigenen Sektion Weaknesses. Diese Sektion listet 96 Punkte ohne CVE-Nummer, davon rund zwanzig mit Sicherheitsbezug, der Rest sind Tests und Aufräumarbeiten.

Kontosperrung, die nicht sperrt. CVE-2026-88770 (Moderat, 6.5) und CVE-2026-16103 (Moderat, 4.3): Beim Device Authorization Grant und bei der CIBA-Token-Einlösung fehlte die Prüfung, ob das Konto wegen Brute-Force gesperrt ist. Die CIBA-Lücke ist eine unvollendete Nacharbeit: Die Sperre war bei der Einleitung bereits nachgezogen, bei der Token-Einlösung aber vergessen worden. Wer den Grant-Ablauf anstoßen konnte, bekam Token für Konten, die gerade wegen Anmeldehäufigkeit gesperrt waren. Das setzt voraus, dass der Angreifer den Ablauf überhaupt starten kann; es unterläuft aber genau den Mechanismus, der ihn stoppen soll.

Dazu die kleinen, aber feinen: Die localhost-Ausnahme von secure-client-uris akzeptierte Angreifer-Domains, die mit localhost beginnen; ein Wildcard-Match in Client-Policies traf Nicht-Subdomain-Suffixe (attackerexample.com besteht gegen *.example.com); SAML-Redirect-Binding konnte durch Parameter-Pollution zu einer Anmeldung im falschen Konto führen, wenn die Redirect-URL weit per Wildcard offen stand.

Warum die Meldung mit dem falschen Datum durchläuft, und warum das zählt

Die Projektseite selbst hat seit GHSA-xpwp-2pcm-8xq3 zu CVE-2026-90997 vom 16. September keine eigene Security-Advisory veröffentlicht, Stand 9. Oktober. Für einzelne der 20 CVEs existieren wohl Einträge in der GitHub-Advisory-Datenbank, etwa GHSA-82wc-7jr6-wxgm zu CVE-2026-93999 vom 19. September. Das sind ungeprüfte Importe des NVD-Eintrags, keine Aussagen der Maintainer. Die Score-Werte zu den 20 Fixes stammen deshalb derzeit aus dem Red-Hat-Tracker und stehen dort auf draft. Die Red-Hat-Build-Variante von Keycloak ist bei CVE-2026-90997 als not affected gelistet, eine RHSA gibt es nicht. Wer Meldungen zu Keycloak-Lücken zitiert, prüft also besser zweimal, welche Quelle die Zahl gesetzt hat: Release-Note, Tracker oder Video.

Die einzige High-Lücke des Fensters ist CVE-2026-90997 (CVSS 7.4, fixed in 26.7.4): Im stateless Betrieb an MySQL oder MariaDB führt ein Missverhältnis bei den geprüften Zeilenzahlen dazu, dass einmal gültige Einzelverwendungen-Token (Client-JWT-Assertions, DPoP-Proofs, TOTP-Codes) erneut akzeptiert werden können. Ohne Authentifizierung erreichbar, Workaround laut Advisory: die stateless-Funktion abschalten. Red Hat nennt zusätzlich den JDBC-Parameter useAffectedRows=true als Abhilfe. Wer auf 26.7.0 bis 26.7.3 an MySQL oder MariaDB stateless betreibt, für den ist das der Treiber zum sofortigen Patchen.

Der Vollständigkeit halber: Ein Backport auf die 26.6-Linie („26.6.8") taucht in Issue-Labels auf, existiert als Release aber nicht. Wer noch auf 26.6.x läuft, wartet auf nichts; es geht direkt auf 26.7.5 oder 26.8.0.

Unser Stand, gemessen am 9. Oktober 2026

Unsere Instanz läuft als Container quay.io/keycloak/keycloak:26.7.1 auf einem dedizierten Host, die Datenbank als keycloak-db auf postgres:17-alpine. Gemessen ist das mit docker inspect auf den Image-Tag, im Compose-File steht die Pinning-Form mit Tag und Digest, sha256:f1f1f01e…c01c6. Die Konfiguration setzt KC_DB=postgres und einen JDBC-Url auf die Postgres; ein Feature-Flag für stateless Betrieb ist nicht gesetzt, die Funktion müsste ausdrücklich aktiviert werden. Damit ist die Bedingung von CVE-2026-90997, stateless an MySQL oder MariaDB, für uns nicht erfüllt. Der Container läuft seit dem 7. Oktober ohne Neustart. Wie diese Instanz als Single Sign-On vor unseren internen Diensten sitzt, haben wir hier beschrieben.

In unserer Release-Übersicht für KW 39 stand 26.7.4 bereits als offene Baustelle, samt dem Hinweis, dass sechs CVEs ungepatcht bleiben, wenn wir noch auf 26.7.3 oder älter sind. Nachgemessen haben wir die laufende Version dort nicht, das war eine Lücke im Ablauf und nicht in der Quelle. Die Messung von heute schließt sie: Wir liegen mit 26.7.1 noch hinter 26.7.4, also auch hinter dem Fix von CVE-2026-90997, und vor allen 20 Fixes der beiden neuen Releases.

Der Schritt auf 26.8.0 ist bei uns kein nacktes compose pull. Der Host bindet den Truststore für die Samba-AD-Certificate als Read-only-Bindung in das Container-Verzeichnis für Truststores, und ein karger Neustauf würde die Anmeldung über das Active Directory still brechen lassen, spätestens beim nächsten Kontakt. Dafür liegt auf dem Host ein eigenes Skript, das die Identitätsdienste in der richtigen Reihenfolge neu hochzieht und sich vorher trocken durchspielen lässt. Bild-Tausch, Datenbank-Sicherung vorher, Truststore-Prüfung nachher. Ein Wartungsfenster dafür ist noch nicht gesetzt. Das ist der Punkt, den dieser Post als Aufgabe an uns selbst zurücklässt.

Was Betreiber jetzt tun

1. Version erst messen: docker inspect --format '{{.Config.Image}}' auf den Keycloak-Container. Wer nach dem Digest gehen will, findet ihn im Compose-File oder über docker images --digests.
2. Alles unter 26.7.5 ist mindestens von einer der beiden Tranchen betroffen. Ziel ist 26.8.0, die Version einen Tag später.
3. Wer 26.7.0 bis 26.7.3 an MySQL oder MariaDB betreibt und die stateless-Funktion nutzt: sofort patchen oder stateless abschalten.
4. Nach dem Upgrade: Prüfen, welche Ressourcen-Server JWTs offline verifizieren statt online zu introspectieren. Bis zum Fix war ein deaktivierter Client für diese Systeme kein Entzug.
5. Admin-Rollen aufräumen: view-clients war vor 26.7.5 mehr als ein Leserecht.

Weiterführende Quellen

• Keycloak 26.7.5 released, Blogpost vom 30. September 2026, vollständige Liste der 14 Sicherheitsfixes
• Keycloak 26.8.0 released, Blogpost vom 1. Oktober 2026, inklusive der Sektion Weaknesses mit 96 Punkten
• Red Hat: CVE-2026-93999, Tracker-Eintrag einer der zehn Produkt-Lücken
• GHSA-xpwp-2pcm-8xq3 / CVE-2026-90997, Advisory vom 16. September 2026
• GitHub-Release 26.8.0 mit Zeitstempel 1. Oktober 2026, 05:57 UTC
• Red Hat: CVE-2026-90997, Tracker-Eintrag mit Scoring-Status