The vulnerability is a privilege escalation issue in Keycloak where an administrator with the manage-clients role could gain realm-admin privileges. This was possible due to insufficient permission checks when managing roles, particularly roles associated with internal clients like realm-management.
The analysis of the patch 39cb8de54c8517efeda4baa8bc314fd40e9c6934 reveals several key changes that fixed the vulnerability:
-
Missing Authorization in Role Management: The updateRole and deleteRole methods in org.keycloak.services.resources.admin.RoleContainerResource were missing a crucial permission check. The patch adds auth.roles().requireManage(role); to both methods, ensuring that the user has the necessary permissions to modify the target role before the operation is performed. The absence of this check is a primary vulnerability.
-
Access to Internal Clients: The canManage and canConfigure methods in org.keycloak.services.resources.admin.fgap.ClientPermissions (and canManage in ClientPermissionsV2) did not prevent administrators with manage-clients from modifying internal, sensitive clients (e.g., realm-management). The patch introduces an isInternal(client) check to explicitly deny management of these clients, closing the main attack vector.
-
Protection of Admin Roles: The canManage method in org.keycloak.services.resources.admin.fgap.RolePermissions was modified to prevent the modification of critical realm administration roles (like admin and create-realm) even by users with manage-realm permissions. This adds another layer of defense.
The exploit would involve an attacker with manage-clients role making an API call to update the realm-admin role (which is part of the internal realm-management client) to add a composite role that they control. This would grant them realm-admin privileges. The functions updateRole and deleteRole would be the entry points for such an attack, and the various canManage functions would be the authorization checks that were bypassed or insufficient. The vulnerability is described as a TOCTOU, which likely refers to the gap between checking permissions (which was insufficient) and the actual modification of the role.