CVE-2026-9795: Keycloak FGAPv2 privilege escalation — a high-privilege path to unauthorised role escalation in the realm

TL;DR — the 90-second summary

What was published?

CVE-2026-9795 (disclosure 28 May 2026, CVSS 7.3 HIGH, CWE-266 Incorrect Privilege Assignment). Class: privilege escalation within a Keycloak realm, triggered by an already authenticated administrator with FGAPv2 permissions. The concrete mechanism at the API level is reduced to a generic description in my available sources (NVD detail, Red Hat CVE detail page, OpenCVE) — a GHSA detail page with a code reproducer was not publicly available at the time of this post.

How bad?

HIGH (CVSS 7.3, vector AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N). Important: Attack Complexity High and Privileges Required High mean the flaw is not a drive-by path — it needs an already authenticated administrator with FGAPv2 permissions and a user interaction. Reach: Scope Changed, confidentiality and integrity each High.

Which Keycloak versions are affected?

Keycloak versions with the FGAPv2 feature enabled. FGAPv2 has been the strategic permissions layer since Keycloak 26.2 and is being extended in the 26.x/27.x releases. For exact fixed version levels see the Keycloak security advisory page and Red Hat errata.

Am I affected?

Affected if your platform uses Keycloak as an identity provider (typical for Symfony/Sylius/TYPO3 setups with OIDC/SAML auth), you have FGAPv2 as the permissions model enabled, and you maintain more than one admin persona in your Keycloak realm. Anyone running Keycloak with only a single realm-admin account is not in this class.

Immediate mitigation?

Three steps. First, check Keycloak version (kc.sh --version) and compare with the Keycloak fix level for CVE-2026-9795. Second, if FGAPv2 is enabled: inventory all delegated admin personas with FGAPv2 permissions and put them under heightened audit log observation. Third, check whether unusual role assignments or scope mappings sit on existing clients.

Severity?

Hero badge high. Active exploitation as of 30 May not publicly documented. The high attack complexity and the required authentication state limit drive-by exploitability.

What happened

On 28 May 2026 Red Hat published CVE-2026-9795, a privilege escalation flaw in the Fine-Grained Admin Permissions v2 layer (FGAPv2) of Keycloak. The flaw carries CVSS 7.3 (HIGH) with the vector AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N and is classified as CWE-266 (Incorrect Privilege Assignment).

Key to the assessment are the vector components Attack Complexity High, Privileges Required High and User Interaction Required: the flaw is not an unauthenticated drive-by path but an escalation class that lifts an already authenticated administrator with FGAPv2 permissions into an unauthorised higher role status. Scope Changed with confidentiality and integrity high shows that the escalation acts beyond the original security boundary on other realm components and thus on user data and realm configuration.

FGAPv2 is the strategic permissions layer introduced by Keycloak from version 26.2 onwards (see Keycloak blog post May 2025, „Achieving Fine-Grained Admin Permissions with Keycloak 26.2“).

Honest note on the source situation: My sources on CVE-2026-9795 (NVD detail, Red Hat CVE detail page, OpenCVE) carry a generic description of the class, but at the time of this post no GHSA detail entry with a code reproducer was publicly reachable. The older secondary collection on the mid-2025 FGAPv2 early phase (CVE-2025-7784, GHSA-27gp-8389-hm4w) is sometimes conflated with CVE-2026-9795 — the mechanism of the older flaw was „manage-users permission → self-assign realm-admin via own user roles“ and is not today's finding.

Methodologically the class remains clear: FGAPv2 is a permission layer in construction, and permission layers of this complexity in practice typically see several correction rounds in the first 12–24 months after introduction. CVE-2025-7784 (Jul 2025) and CVE-2026-9795 (May 2026) are both symptoms of this build-up phase.

Technical analysis

Structurally the FGAPv2 class — both CVE-2025-7784 (Jul 2025) and CVE-2026-9795 (May 2026) — shows a very typical form of privilege escalation bug in complex permission systems: the permission boundary for the action is correct, but the permission boundary for the action effect is not. The sub-admin may manage a particular resource — that is the permission FGAPv2 explicitly checks. But the sub-admin may also implicitly perform concrete modifications that have effects beyond the originally granted permission — and these implicit second permissions are the ones they should not have.

This class of bugs appears in every sufficiently complex permission system. Historical templates reach from Linux capabilities bugs through Kubernetes RBAC escalation paths (CVE-2018-1002105) to more recent AWS IAM classes where iam:PassRole without an explicit trust policy boundary gave the lever for lateral privesc. Structural lesson: for every permission „X can modify Y“ it must be explicitly checked which modifications are allowed. Implicit „X can transform Y into any form“ is a bug template.

Methodologically FGAPv2 has taken the right direction in its roadmap step over FGAPv1 — finer permission granularity, explicit resource permission separation. But: every new permission layer has an introduction phase in which not all sub-permission paths are explicitly modelled. CVE-2026-9795 is exactly such a sub-path that slipped through the FGAPv2 modelling.

Link to today's situation: CVE-2026-9795 sits in the same Red Hat disclosure drop as CVE-2026-4408 Samba, CVE-2026-44604 rpmuncompress, CVE-2026-42965 + CVE-2026-46579 OpenShift Router and CVE-2026-9804 KubeVirt — six Red Hat component disclosures in 72 hours.

What this means for the Mittelstand

Keycloak is a selectively used but stably anchored stack in the German Mittelstand. Anyone running a TYPO3, Sylius or Symfony platform with a serious identity layer — that is, not only local users in the platform database but a real OIDC/OAuth2/SAML federation against a central identity source — in many cases uses Keycloak.

The configuration variant relevant for Mittelstand practice is the one with multiple admin personas: a central cloud/IT-ops admin with realm-admin access, plus several sub-admins with restricted permissions — typically a marketing sub-admin for configuring marketing clients, a service-desk sub-admin for user management, an application-owner sub-admin. FGAPv2 is built precisely for this delegation situation — and that is exactly where the escalation path sits.

On the compliance side the finding acts on multiple axes. GDPR Art. 32 affects every platform whose identity layer processes personal data — which is the case for Keycloak by definition. A privilege escalation in the identity layer is a technical-measures gap under Annex 1; under Recital 75 it may be reportable once a concrete escalation is demonstrated. NIS-2 Art. 21 demands concrete identity-and-access-management discipline. ISO 27001 Annex A.5.18 (Access Control Policy) requires permission assignment and audit logs to be kept in a continuous process.

Operationally the inventory question is: how many realms in your Keycloak instance use FGAPv2, and how many delegated admin personas exist in those realms?

What this means for technical development

Architecturally CVE-2026-9795 forces three disciplines.

First, token content audit on the application side. If your application performs role-based authorisation against token claims (standard for OIDC resource servers in Symfony, Sylius, TYPO3 with oidc_login or custom OAuth2 bundles), the application should explicitly check whether the token carries a claim semantically matching the application — not blindly trust every role contained in the token. A marketing application should not accept a realm-admin role.

Second, permission system design with „effect permission“ as its own category. If you design your own permission system, you should ask for every action: what can this action change in the system? Which of these changes depend on a separate effect permission? Configurations referencing other resources need separate permission checks.

Third, IAM audit log obligation. Keycloak writes FGAPv2 permission changes, scope mapping modifications and role assignments into an audit log (Events tab or via the event listener SPI). Anyone not collecting this log centrally (SIEM, Elastic, Loki + Grafana) sees a privilege escalation only when it is exploited — not when it happens.

Concrete recommendation

In this order. First, inventory today: per Keycloak instance check which realms have FGAPv2 enabled and which delegated admin personas with client management permission exist. Second, scope mapping audit: walk all clients via the Admin REST API and list their realm scope mappings; mark each unusual high-privilege role. Third, patch run: lift to the Keycloak fix level for CVE-2026-9795; for container-based deployments (Quay.io image or own build) pull the new image tag and roll. Fourth, stopgap for setups that cannot patch immediately: temporarily remove client management permission from delegated admins, or reduce their permissions to specific clients known to be safe. Fifth, application-side hardening: in Symfony/Sylius/TYPO3 backends processing OIDC tokens, explicitly check that token claims match the application. Sixth, audit log pipeline: pipe the Keycloak event listener to a central log collector.

If these steps do not run from your own capacity, talk to me: I deliver identity platforms in which Keycloak permissions, scope mappings and audit logs are kept in a continuous maintenance layer.

This post reflects my technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• NVD — CVE-2026-9795 detail page (as of 30 May 2026, primary source for CVSS vector and CWE classification)
• Red Hat Customer Portal — CVE-2026-9795 (as of 30 May 2026, primary source for severity and affected products)
• OpenCVE — CVE-2026-9795 (as of 30 May 2026)
• Keycloak Blog — Achieving Fine-Grained Admin Permissions with Keycloak 26.2 (May 2025, FGAPv2 introduction documentation)
• Keycloak GHSA-27gp-8389-hm4w / CVE-2025-7784 (Jul 2025, separate FGAPv2 flaw — as class context, not as CVE-2026-9795 source)