Back github.com

Keycloak Issues 53060

github.com • October 13, 2026

A flaw was found in Keycloak's Admin REST API group-membership endpoints. The PUT /admin/realms/{realm}/users/{id}/groups/{groupId} endpoint and the groups list accepted during user creation both verify only that the caller can manage group membership, without inspecting the roles the target group confers. A delegated administrator holding only the manage-users role can add their own account, or a newly created account, to a pre-existing group that maps realm-admin , thereby inheriting full administrative control of the realm. The direct role-assignment path correctly refuses this operation with HTTP 403, but the group-membership path bypasses that check entirely.

This is tracked as CVE-2026-94000 .

Reproduced against Keycloak 26.7.3 ( quay.io/keycloak/keycloak:26.7.3 ).

Before adding a user to a group, Keycloak should verify that the caller is entitled to every role the group confers. If the group maps an administrative role the caller does not already hold, the request should be rejected with HTTP 403 Forbidden — consistent with the behavior of the direct role-assignment endpoint ( POST /admin/realms/{realm}/users/{id}/role-mappings/realm ), which already enforces this check via requireMapRole / checkAdminRoles .

PUT /admin/realms/{realm}/users/{id}/groups/{groupId} succeeds with HTTP 204 regardless of which roles the target group maps. A manage-users holder who joins a group that maps realm-admin obtains full realm-admin privileges on their token, including the ability to grant realm-admin to other users — an action Keycloak permits only to callers who already hold that role.

Root cause: UserResource.joinGroup calls only requireManageGroupMembership and requireManageMembership , both of which are satisfied unconditionally by manage-users . The UsersResource.createUser groups callback has the identical gap. Neither call site checks the roles the group carries. The SCIM path already has an equivalent guard ( isAdminGroup ); the Admin REST path does not.

Related issues: [KEYCLOAK-883] - Code cleanup and refactoring. #970 / CVE-2026-18571 fixed the createGroups callback but did not fix UserResource.joinGroup . KEYCLOAK-1213 Installation file for bearer-only doesn't include auth-ser... #1148 is a sibling issue achieving the same escalation via composite role name-only matching. phased broker mapper changes #1146 shows this path is reachable from view-clients by chaining through a service-account secret.

CVE record:

This issue was originally tracked in the private repository. Migrated by @abstractj .

abstractj added priority/important Must be worked on very soon Must be worked on very soon area/admin/fine-grained-permissions Fine-grained admin permissions (FGAP v2) — per-resource authorization Fine-grained admin permissions (FGAP v2) — per-resource authorization kind/cve Issues identified as CVEs on third-party dependencies, or issues which Keycloak is not affected Issues identified as CVEs on third-party dependencies, or issues which Keycloak is not affected backport/main on Sep 22, 2026

abstractj added the cve issue type on Sep 22, 2026

abstractj added team/core-iam backport/26.4 backport/26.6 on Sep 22, 2026

github-project-automation added this to Keycloak Roadmap on Sep 22, 2026

github-project-automation moved this to Open in Keycloak Roadmap on Sep 22, 2026

ahus1 changed the title [-] [CVE-2026-94000] Keycloak: A delegated admin with only `manage-users` can become `realm-admin` by joining (or being created into) a group that maps an admin role [/-] [+] [CVE-2026-94000] A delegated admin with only `manage-users` can become `realm-admin` by joining (or being created into) a group that maps an admin role [/+] on Sep 22, 2026

vramik self-assigned this on Sep 23, 2026

pedroigor added a commit that references this issue on Sep 30, 2026 Prevent privilege escalation via group membership to admin-role groups This issue will close once commit 308b6b2 is merged into the 'master' branch. 308b6b2