Keycloak 26.6.2 Security: HTTP/2 und WebAuthn

Q: Wie merke ich, ob ein Angriff bereits stattgefunden hat?

Schau in die Keycloak-Logs nach ungewöhnlich vielen 'http2 stream reset'-Events oder Connection-Drop-Patterns. Im Quarkus-Server-Log tauchen Stream-Reset-Events explizit auf. Bei massivem CPU-Verbrauch ohne sichtbaren Lastgrund oder hängenden Realm-Operations: das könnte ein bereits stattgefundener DoS-Versuch sein. WebAuthn-Manipulationen sind schwerer zu erkennen — hier lohnt sich ein Blick in die User-Sessions auf ungewöhnliche Origin-Header.

FOLGE-PATCH wenige Tage nach 26.6.1

Die Keycloak-Maintainer haben am 19. Mai 2026 Keycloak 26.6.2 released — und das so kurz nach 26.6.1 (mit 10 CVEs), dass sich die Frage stellt: hat 26.6.1 was offen gelassen? Antwort: ja, ein paar Pfade waren noch nicht ganz dicht.

Die wichtigste Klasse von Fixes betrifft HTTP/2. Mehrere Stream-Reset-Pfade waren in 26.6.1 noch nicht vollständig abgedichtet — ein Angreifer konnte unter bestimmten Bedingungen DoS gegen den Auth-Server fahren. Auch ein paar XSS-Vektoren in Admin-Konsolen-Templates und WebAuthn-Authentifizierungs-Wege kommen in 26.6.2 sauberer.

WAS wird konkret gestopft

HTTP/2 Stream-Resets: Folge-Patches zu den Rapid-Reset-artigen Angriffen — Keycloak-eigener Reverse-Proxy-Pfad ist jetzt strikter
XSS in Admin-Konsole: Mehrere Stellen, in denen User-Input nicht escaped wurde, sind nachgeschärft
WebAuthn: Stricter Origin-Check beim FIDO-Flow — Spoofing über Subdomain-Trickserei nicht mehr möglich
Access-Token-Replay: Token-Caches mit zu langer TTL können in bestimmten Setups zu Replay-Risiko geführt haben
Realm-Roles: Race-Condition beim parallelen Rollen-Update

Anders als bei 26.6.1 ist keine RCE dabei. Die Lücken sind alle Defense-in-Depth-relevant — Profis ziehen den Patch trotzdem zeitnah.

WARUM 26.6.1 NICHT gereicht hat

26.6.1 war der grosse 10-CVE-Sammler vom 12. Mai. Beim Audit danach haben Maintainer und Sicherheitsforscher Folgeketten gefunden, die direkt im Code-Path lagen, aber zur Veröffentlichung von 26.6.1 noch nicht vollständig analysiert waren. Statt 26.6.1.1 als Hotfix zu ziehen, hat das Team einen sauberen 26.6.2-Bump gemacht.

Für den User bedeutet das: keine Trickserei mit Mini-Patches, sondern direkt eine Folge-Version mit klarer Changelog-Linie. Das macht die Migration einfacher.

SO updatest du sauber

Standard-Verfahren: Realm-Export sichern, Datenbank-Backup ziehen, Container-Image bumpen.

Quarkus-Distribution: kc.sh build --db=<your-db> nach Update der JAR
Container: Image auf quay.io/keycloak/keycloak:26.6.2 ziehen
Operator: Custom-Resource Keycloak.image aktualisieren

Das 26.6-Stream bleibt mit Zero-Downtime-Patching kompatibel — Cluster-Updates rollen sauber durch, wenn deine Tokens vor dem Patch nicht zu lange ausgestellt waren.

WAS noch im Mai-Stream kommt

Keycloak veröffentlicht alle 1-2 Monate. Bis zum nächsten Minor (26.7) sind voraussichtlich noch ein bis zwei kleinere Bugfix-Releases im 26.6-Stream zu erwarten. Wer den Operator nutzt, sollte sich die updateStrategy: rolling-Konfiguration noch einmal anschauen — bei Token-lastigen Setups verhindert das ungewollte Logout-Wellen.

FAZIT

26.6.2 ist kein optionales Update. HTTP/2-DoS-Lücken sind besonders unangenehm, weil sie deinen Auth-Server zum Single-Point-of-Failure für Login-Flows machen. Wer Keycloak als zentralen SSO-Provider betreibt — und das tun viele Homelab- und Enterprise-Setups — sollte den Patch noch dieses Wochenende durchziehen.

Häufige Fragen

Muss ich erst auf 26.6.1, oder kann ich direkt auf 26.6.2?

Direkt auf 26.6.2. Es gibt keinen Migrations-Schritt, der explizit 26.6.1 voraussetzt. Solange dein Ausgangs-Stand 26.6.0 oder neuer ist, läuft das Update sauber. Bei älteren Major-Versionen (26.5, 26.4) zuerst auf den jeweils letzten Patch der Minor-Linie und dann auf 26.6.2.

Welche meiner Setups sind besonders gefährdet?

Keycloak-Instanzen ohne vorgelagerten Reverse-Proxy (HAProxy, Nginx, Traefik) und solche mit aktivem HTTP/2 direkt am Quarkus-Server. Wer Keycloak hinter einem stabilen Reverse-Proxy fährt, hat einen Mitigation-Layer, aber das schliesst HTTP/2-Lücken auf der internen Strecke nicht komplett aus.

Wie merke ich, ob ein Angriff bereits stattgefunden hat?

Schau in die Keycloak-Logs nach ungewöhnlich vielen ‚http2 stream reset‘-Events oder Connection-Drop-Patterns. Im Quarkus-Server-Log tauchen Stream-Reset-Events explizit auf. Bei massivem CPU-Verbrauch ohne sichtbaren Lastgrund oder hängenden Realm-Operations: das könnte ein bereits stattgefundener DoS-Versuch sein. WebAuthn-Manipulationen sind schwerer zu erkennen — hier lohnt sich ein Blick in die User-Sessions auf ungewöhnliche Origin-Header.

Quellen: keycloak.org 26.6.2 · GitHub Releases

KEYCLOAK-ALARM! 26.6.2 stopft JETZT die nächste HTTP/2-Lücke — und DEIN SSO muss SOFORT nachziehen