CVE-2026-17526: Keycloak Impersonation Escalates to Realm Admin

Last updated: September 2026

CVE-2026-17526 is a privilege escalation in Keycloak where a user holding the impersonation role could impersonate a realm administrator, and therefore inherit everything that administrator can do. The published community release carrying the fix is 26.7.4, tagged on 16 September 2026, and the same change is on the 26.6 and 26.4 maintenance branches upstream. The attack requires an existing privileged role, so it is not a remote unauthenticated takeover, but it matters because impersonation is routinely granted to support staff who are deliberately not administrators. The fix adds a check that was missing: before allowing impersonation, Keycloak now refuses when the target holds an admin role that the caller does not also hold.

This is a single-CVE brief. Keycloak 26.7.4 shipped six security fixes in total, listed on the 26.7.4 release on GitHub, and the previous release line’s much larger set is covered in our 26.7.3 patch checklist.

What does the impersonation role actually grant?

The impersonation role lets its holder start a session as another user, without that user’s password. In Keycloak it is a client role on the realm-management client, and it exists so support and operations staff can reproduce what a customer sees.

Two details in the 26.7.4 source are worth knowing before the CVE itself. First, impersonation sits behind a feature flag: the endpoint calls ProfileHelper.requireFeature(Profile.Feature.IMPERSONATION) before doing anything, so a build with the feature disabled is not exposed. Second, the role is created and wired at realm setup by ImpersonationConstants, which adds it as a composite of realm-admin (and to the master realm’s admin role for the per-realm admin client). Realm administrators therefore hold impersonation by default, but the role is also routinely granted on its own to support groups holding no other administrative role. That second population is the one this CVE mattered to.

The endpoint already refused some targets before this CVE. Service accounts cannot be impersonated, and neither can disabled users. It also writes an audit trail, emitting an IMPERSONATE event and stamping the session with IMPERSONATOR_ID and IMPERSONATOR_USERNAME notes, so the resulting session is attributable rather than anonymous.

What it did not check was whether the target was more privileged than the caller.

What did CVE-2026-17526 allow?

It allowed a holder of the impersonation role to open a session as a realm administrator, and from there use the admin console and admin REST API with that administrator’s rights: managing users, clients, roles, and the realm itself. The GitHub advisory GHSA-j7cq-x5cp-qpcx records it as CVSS 7.2, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, under CWE-862, missing authorization. The PR:H component is the part worth reading: the caller needs a privileged role before any of this starts.

The practical framing is a boundary failure rather than a break-in. Consider the common support setup: a helpdesk group holds view-users, manage-users and impersonation, deliberately without realm-admin, on the theory that support can help users but not reconfigure the realm. Before the fix, that boundary did not hold, because one of the users the helpdesk could impersonate was an administrator.

The detail worth taking to your own realm: the exposure scales with how many admin accounts are ordinary, impersonatable user accounts in the same realm. A realm where administrators are regular users with extra roles hands the escalation a target. A realm where admin duties live in a separate, dedicated realm gives it nothing local to aim at.

For the wider delegated-admin model that this interacts with, see fine-grained authorization in Keycloak, and for a recent parallel in the Organizations feature, the Organizations CVE brief.

What changed in the 26.7.4 fix?

The patch lands in UserPermissions, in the fine-grained admin permissions package, and it is small enough to read in full. Before 26.7.4, the permission check ran canImpersonate() for the caller and then isImpersonatable(user, requester) for the target. The fix inserts a third condition between them: a new hasHigherPrivilegesThanAdmin(target) test, which refuses impersonation when it returns true.

The logic of that helper is the interesting part:

• If the caller is a full realm admin, it returns false immediately. A realm admin already holds everything, so impersonating an administrator gains them nothing.
• Otherwise it walks every role in AdminRoles.ALL_ROLES, looks each one up on the realm-management client, and checks whether the target holds it while the caller does not.
• It repeats that comparison against realm-level roles when the realm in question is the administration realm, which is the master-realm case.
• Any role the target has and the caller lacks makes the target off limits.

The same helper is applied in UserPermissionsV2, so realms running fine-grained admin permissions v2 are covered by the same logic rather than a separate code path.

In plain terms, Keycloak now refuses to let you impersonate someone more privileged than you are. The relative comparison is what makes it work, rather than a flat “administrators may not be impersonated” rule that would have broken legitimate admin-to-admin support.

One consequence to plan for: because the test is relative, the same helpdesk account may now be able to impersonate one colleague and not another, depending on the roles each holds. If your support runbook assumed impersonation always works, expect some 403 responses after upgrading, and treat them as the control functioning rather than a regression.

Which Keycloak versions carry the fix?

The published community release carrying the fix is 26.7.4, tagged 16 September 2026. The same change also went to the maintenance branches: we checked the upstream tags and hasHigherPrivilegesThanAdmin is present in 26.6.7 and 26.4.16 (both tagged 7 September 2026) and absent from the preceding 26.6.6 and 26.4.15. Older minor lines do receive these fixes rather than being left behind on the newest minor.

One caveat that matters if you are planning an upgrade from this post. Those two maintenance tags do not have their own release entry on keycloak.org, whose published set for the 26.6 and 26.4 lines currently stops earlier. A tag is not automatically a download. If you run a community build, 26.7.4 is the version to move to. If you run a vendor build or track a maintenance branch, check that channel for the corresponding patch rather than assuming the tag is available to you.

There is also no 26.8.0 release as of this writing. It appears in the issue tracker as a future target, which is worth knowing if you read the upstream issue and took its version list as a list of shipped releases.

The version-strategy question underneath is genuinely yours to answer: a point release on your current line is the low-risk move, and a jump to the newest minor is the one that needs a test pass. We cover the trade-off in our Keycloak upgrade strategy guide. Whatever you pick, confirm what you are actually running before you plan the change, since a container tag is not always what got deployed.

Who is actually exposed?

Run through four questions, in order:

The second question is the one that catches people out, because impersonation is often granted through a group rather than directly, and a scan of individually assigned roles misses it. Both halves are available from the admin REST API:

GET /admin/realms/{realm}/clients/{realm-management-id}/roles/impersonation/users
GET /admin/realms/{realm}/clients/{realm-management-id}/roles/impersonation/groups

The first returns users with the role assigned directly, the second the groups that carry it, and you need both to get a complete list. Our admin REST API guide covers authenticating those calls.

What to do if you cannot patch today

Patching is the fix, and the compensating controls are genuinely partial, so treat these as a bridge rather than a resolution.

The strongest short-term move is to reduce who holds the role. Impersonation is a break-glass capability that tends to accumulate as a convenience, and most support workflows need it far less often than the grant list implies. Removing it from standing groups and granting it per incident shrinks the window without changing any code.

If the feature is not in active use, disabling it at the server level makes the endpoint refuse every call, since the handler checks the feature flag before the permission check.

Monitoring helps you detect rather than prevent. IMPERSONATE events carry the impersonator’s username and realm, so an alert on impersonation targeting any account that holds an administrative role is cheap to write and a reasonable standing control after you patch. Sending events somewhere that can evaluate that rule is covered in forwarding Keycloak events to a SIEM.

The structural fix outlives this CVE: keep administrative accounts out of the realm your support staff operates on. Our impersonation operations guide covers the day-to-day practice, and the broader realm review lives in the Keycloak security hardening checklist.

Frequently asked questions

Is CVE-2026-17526 remotely exploitable without credentials?

No. The CVSS vector recorded in GHSA-j7cq-x5cp-qpcx is PR:H, requiring high privileges, and the code path is the authenticated admin impersonation endpoint. An attacker needs an account already holding the impersonation role, which makes this an escalation from a partially trusted position rather than an external entry point.

Does granting realm-admin also grant impersonation in Keycloak?

Yes. Keycloak adds impersonation as a composite of realm-admin at realm setup, and to the master realm’s admin role for the per-realm admin client. It is also grantable on its own, so an audit has to enumerate direct, group and composite assignments rather than assume only realm admins hold it.

Which Keycloak version fixes CVE-2026-17526?

Keycloak 26.7.4, tagged 16 September 2026, is the published community release carrying the fix. The same change is on the 26.6 and 26.4 maintenance branches upstream, tagged 26.6.7 and 26.4.16. There is no 26.8.0 release as of this writing, despite the version appearing in the upstream issue as a target.

Will the fix break existing support workflows?

It can, by design. After upgrading, a support account cannot impersonate a user holding admin roles it does not hold itself, so some previously working impersonations now fail with a 403. Full realm admins are unaffected, since the check exempts them.

How do I find everyone who holds the impersonation role?

Query the realm-management client role through the admin REST API using both the /users and /groups endpoints for the role, since the first returns only direct assignments. Impersonation is commonly granted through a support group, so an audit of directly assigned roles alone will understate who holds it.

Sources

• Keycloak, “Release 26.7.4,” 16 September 2026, https://github.com/keycloak/keycloak/releases/tag/26.7.4
• GitHub Advisory Database, “GHSA-j7cq-x5cp-qpcx” (CVE-2026-17526), https://github.com/advisories/GHSA-j7cq-x5cp-qpcx
• Keycloak, issue #52838, “[CVE-2026-17526] Privilege escalation: the ‘impersonation’ role can impersonate a realm administrator,” https://github.com/keycloak/keycloak/issues/52838
• Keycloak, UserPermissions, UserPermissionsV2, ImpersonationConstants and UserResource at release tag 26.7.4, https://github.com/keycloak/keycloak/tree/26.7.4