CVE-2026-9795: Keycloak FGAPv2 Privilege Escalation — High-Privilege-Pfad zur unautorisierten Rollen-Eskalation im Realm

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

CVE-2026-9795 (Disclosure 28.05.2026, CVSS 7.3 High, CWE-266 Incorrect Privilege Assignment). Klasse: Privilege Escalation innerhalb eines Keycloak-Realms, ausgelöst von einem bereits authentifizierten Administrator mit FGAPv2-Permissions. Der konkrete Mechanismus auf API-Ebene ist in den uns vorliegenden Quellen (NVD-Detail, Red-Hat-CVE-Detail-Page, OpenCVE) auf eine generische Beschreibung verkürzt — eine GHSA-Detail-Seite mit Code-Reproducer war zum Zeitpunkt dieses Posts nicht öffentlich.

Wie schwer?

Hoch (CVSS 7.3, Vektor AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N). Wichtig: Attack Complexity High und Privileges Required High bedeuten, dass die Lücke kein Drive-by-Pfad ist — sie braucht einen bereits authentifizierten Administrator mit FGAPv2-Permissions und eine User-Interaction. Reichweite: Scope Changed, Vertraulichkeit und Integrität jeweils High.

Welche Keycloak-Versionen sind betroffen?

Keycloak-Versionen mit aktiviertem FGAPv2-Feature. FGAPv2 ist seit Keycloak 26.2 die strategische Permissions-Schicht und wird in den 26.x-/27.x-Releases ausgebaut. Für die exakten Fix-Version-Stände siehe die Keycloak-Security-Advisory-Seite und Red-Hat-Errata.

Bin ich als Moselwal-Kunde betroffen?

Betroffen, wenn Ihre Plattform Keycloak als Identity-Provider einsetzt (typisch für Symfony-/Sylius-/TYPO3-Setups mit OIDC/SAML-Auth), Sie FGAPv2 als Permissions-Modell aktiviert haben, und Sie mehr als einen Administrator-Persona in Ihrem Keycloak-Realm pflegen. Wer Keycloak nur mit einem einzigen Realm-Admin-Account pflegt, hat die Klasse nicht.

Sofort-Mitigation?

Drei Schritte. Erstens, Keycloak-Version prüfen (kc.sh --version) und gegen den Keycloak-Fix-Stand für CVE-2026-9795 abgleichen. Zweitens, wenn FGAPv2 aktiviert ist: alle delegierten Admin-Personas mit FGAPv2-Permissions inventarisieren und in erhöhte Audit-Log-Beobachtung nehmen. Drittens, prüfen, ob auf bestehenden Clients ungewöhnliche Rollen-Zuweisungen oder Scope-Mappings sitzen.

Kritikalität?

Hero-Badge high. Aktive Ausnutzung Stand 30.05. nicht öffentlich dokumentiert. Die hohe Attack Complexity und der erforderliche Authentifizierungs-Stand begrenzen die Drive-by-Ausnutzbarkeit.

Was ist passiert

Red Hat hat am 28. Mai 2026 mit CVE-2026-9795 eine Privilege-Escalation-Lücke in der Fine-Grained-Admin-Permissions-v2-Schicht (FGAPv2) von Keycloak öffentlich gemacht. Die Lücke trägt CVSS 7.3 (High) mit dem Vektor AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N und ist als CWE-266 (Incorrect Privilege Assignment) klassifiziert.

Wichtig in der Bewertung sind die Vektor-Komponenten Attack Complexity High, Privileges Required High und User Interaction Required: die Lücke ist kein unauthentifizierter Drive-by-Pfad, sondern eine Eskalations-Klasse, die einen bereits authentifizierten Administrator mit FGAPv2-Permissions in einen unautorisiert höheren Rollen-Status hebt. Scope Changed mit Vertraulichkeit-High und Integrität-High zeigt, dass die Eskalation aus der ursprünglichen Sicherheits-Boundary heraus auf andere Realm-Komponenten und damit auf Benutzer-Daten und Realm-Konfiguration wirkt.

FGAPv2 ist die strategische Permissions-Schicht, die Keycloak ab Version 26.2 eingeführt hat (siehe Keycloak-Blog-Eintrag vom Mai 2025 „Achieving Fine-Grained Admin Permissions with Keycloak 26.2“). Sie erlaubt eine deutlich feinere Delegation von Admin-Permissions als das Legacy-Modell FGAPv1.

Ehrlicher Hinweis zur Quellenlage: Die uns vorliegenden Quellen zu CVE-2026-9795 (NVD-Detail, Red-Hat-CVE-Detail-Page, OpenCVE) tragen eine generische Beschreibung der Klasse, aber zum Zeitpunkt dieses Posts war kein GHSA-Detail-Eintrag mit Code-Reproducer öffentlich erreichbar. Die ältere Sekundärquellen-Sammlung zur Mitte-2025-FGAPv2-Frühphase (CVE-2025-7784, GHSA-27gp-8389-hm4w) wird gelegentlich fälschlich mit CVE-2026-9795 vermischt — der Mechanismus der älteren Lücke war „manage-users-Permission → self-assign realm-admin via own user roles“ und ist nicht der heutige Befund. Bevor Sie diesen Post veröffentlichen, sollte die Keycloak-Release-Notes-Seite für die nächste Patch-Version gegengeprüft werden.

Methodisch bleibt die Klasse aber klar: FGAPv2 ist eine Permission-Schicht im Aufbau, und Permission-Schichten dieser Komplexität haben in der Praxis erfahrungsgemäß mehrere Korrektur-Runden in den ersten 12–24 Monaten nach Einführung. CVE-2025-7784 (Jul 2025) und CVE-2026-9795 (Mai 2026) sind beide Symptome dieser Aufbau-Phase.

Technische Einordnung

Strukturell zeigt die FGAPv2-Klasse — sowohl CVE-2025-7784 (Jul 2025) als auch CVE-2026-9795 (Mai 2026) — eine sehr typische Form von Privilege-Escalation-Bug in komplexen Permission-Systemen: die Permission-Boundary für die Action stimmt, aber die Permission-Boundary für den Action-Effekt stimmt nicht. Der Sub-Admin darf eine bestimmte Resource verwalten — das ist die Permission, die FGAPv2 explizit prüft. Der Sub-Admin darf aber implizit auch konkrete Modifikationen vornehmen, die Effekte über die ursprünglich vergebene Permission hinaus haben — und diese impliziten zweiten Permissions sind die, die er eigentlich nicht haben sollte.

Diese Klasse von Bugs taucht in jedem hinreichend komplexen Permission-System auf. Historische Vorlagen reichen von Linux-Capabilities-Bugs über Kubernetes-RBAC-Eskalations-Pfade (CVE-2018-1002105) bis zu jüngeren AWS-IAM-Klassen, in denen iam:PassRole ohne explizite Trust-Policy-Boundary den Hebel zur Lateral-Privesc gegeben hat. Die strukturelle Lehre: für jede Permission „X kann Y modifizieren“ ist explizit zu prüfen, welche Modifikationen erlaubt sind. Implizite „X kann Y in jede Form bringen“ ist eine Bug-Vorlage.

Methodisch hat FGAPv2 in seinem Roadmap-Schritt gegenüber FGAPv1 die richtige Richtung eingeschlagen — feinere Permission-Granularität, explizite Resource-Permission-Trennung. Aber: jede neue Permission-Schicht hat eine Einführungsphase, in der nicht alle Sub-Permission-Pfade explizit modelliert sind. CVE-2026-9795 ist genau so ein Sub-Pfad, der bei der FGAPv2-Modellierung durchgerutscht ist.

Die Verbindung zur Tageslage: CVE-2026-9795 sitzt im selben Red-Hat-Disclosure-Drop wie CVE-2026-4408 Samba, CVE-2026-44604 rpmuncompress, CVE-2026-42965 + CVE-2026-46579 OpenShift Router und CVE-2026-9804 KubeVirt — sechs Red-Hat-Komponenten-Disclosures in 72 Stunden.

Bedeutung für den Mittelstand

Keycloak ist im DACH-Mittelstand ein selektiv eingesetzter, aber stabil verankerter Stack. Wer eine TYPO3-, Sylius- oder Symfony-Plattform mit einer ernsthaften Identity-Schicht betreibt — also nicht nur lokale User in der Plattform-Datenbank, sondern eine echte OIDC-/OAuth2-/SAML-Federation gegen eine zentrale Identitäts-Quelle —, hat in vielen Fällen Keycloak im Einsatz.

Die für die Mittelstands-Praxis relevante Konfigurations-Variante ist die mit mehreren Admin-Personas: ein zentraler Cloud-/IT-Ops-Admin mit Realm-Admin-Zugriff, plus mehrere Sub-Admins mit eingeschränkten Permissions — typisch ein Marketing-Sub-Admin für die Konfiguration der Marketing-Clients, ein Service-Desk-Sub-Admin für User-Management, ein Anwendungs-Owner-Sub-Admin. FGAPv2 ist genau für diese Delegations-Lage gebaut — und genau dort sitzt der Eskalations-Pfad.

Compliance-seitig wirkt der Befund auf mehreren Achsen. DSGVO Art. 32 trifft jede Plattform, deren Identity-Schicht personenbezogene Daten verarbeitet — was bei Keycloak per Definition der Fall ist. Eine Privilege-Escalation in der Identity-Schicht ist eine technische Maßnahmen-Lücke nach Anlage 1; nach Erwägungsgrund 75 ggf. meldepflichtig, sobald eine konkrete Eskalation nachgewiesen ist. NIS-2 Art. 21 fordert konkrete Identity-and-Access-Management-Disziplin. ISO 27001 Annex A.5.18 (Access Control Policy) verlangt, dass Permission-Vergabe und Audit-Logs in einem laufenden Prozess geführt werden.

Operativ ist die Inventur-Frage: wie viele Realms in Ihrer Keycloak-Instanz nutzen FGAPv2, und wie viele delegierte Admin-Personas existieren in diesen Realms?

Bedeutung für die technische Entwicklung

Architektonisch zwingt CVE-2026-9795 zu drei Disziplinen.

Erstens, Token-Inhalt-Audit auf der Anwendungs-Seite. Wenn Ihre Anwendung Rollen-basierte Authorisierung gegen Token-Claims macht (Standard für OIDC-Resource-Server in Symfony, Sylius, TYPO3 mit oidc_login oder Custom-OAuth2-Bundles), sollte die Anwendung explizit prüfen, ob der Token einen Claim trägt, der semantisch zu der Application passt — und nicht blind jeder Rolle vertrauen, die im Token steht. Eine Marketing-Anwendung sollte keine realm-admin-Rolle akzeptieren.

Zweitens, Permission-System-Design mit „Effekt-Permission“ als eigene Kategorie. Wer ein eigenes Permission-System designt, sollte für jede Action die Frage stellen: was kann diese Action im System verändern? Welche dieser Veränderungen sind auf eine separate Effekt-Permission angewiesen? Konfigurationen, die andere Resources referenzieren, brauchen separate Permission-Checks.

Drittens, IAM-Audit-Log-Pflicht. Keycloak schreibt FGAPv2-Permission-Änderungen, Scope-Mapping-Modifikationen und Role-Assignments in einen Audit-Log (Events-Tab oder über das Event-Listener-SPI). Wer diesen Log nicht zentral sammelt (SIEM, Elastic, Loki + Grafana), sieht eine Privilege-Eskalation erst, wenn sie ausgenutzt wird — nicht, wenn sie passiert.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, Inventur heute: pro Keycloak-Instanz prüfen, welche Realms FGAPv2 aktiviert haben und welche delegierten Admin-Personas mit Client-Management-Permission existieren. Zweitens, Scope-Mapping-Audit: per Admin-REST-API alle Clients durchlaufen und ihre Realm-Scope-Mappings auflisten; jede ungewöhnliche hochprivilegierte Rolle markieren. Drittens, Patch-Lauf: auf den Keycloak-Fix-Stand für CVE-2026-9795 heben; bei Container-basierten Deployments (Quay.io Image oder eigener Build) den neuen Image-Tag ziehen und rollen. Viertens, Stopgap für nicht-sofort-patchbare Setups: delegierten Admins mit Client-Management-Permission temporär entziehen, oder ihre Permissions auf die expliziten Clients reduzieren. Fünftens, Anwendungs-seitige Härtung: in Symfony-/Sylius-/TYPO3-Backends, die OIDC-Tokens verarbeiten, explizit prüfen, dass die Token-Claims zur Application passen. Sechstens, Audit-Log-Pipeline: Keycloak-Event-Listener auf eine zentrale Log-Sammelstelle pipen.

Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal richtet Identity-Plattformen, in denen Keycloak-Permissions, Scope-Mappings und Audit-Logs in einer laufenden Pflege-Schicht geführt werden.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• NVD — CVE-2026-9795 Detail-Seite (Stand 30.05.2026, primäre Quelle für CVSS-Vektor und CWE-Klassifikation)
• Red Hat Customer Portal — CVE-2026-9795 (Stand 30.05.2026, primäre Quelle für Severity und Affected Products)
• OpenCVE — CVE-2026-9795 (Stand 30.05.2026)
• Keycloak Blog — Achieving Fine-Grained Admin Permissions with Keycloak 26.2 (Mai 2025, FGAPv2-Einführungsdokumentation)
• Keycloak GHSA-27gp-8389-hm4w / CVE-2025-7784 (Jul 2025, separate FGAPv2-Lücke — als Klassen-Kontext, nicht als CVE-2026-9795-Quelle)