CVE-2026-97177 in Keycloak
Summary
by MITRE • 09/24/2026
A flaw was found in the user update mechanism of the Keycloak Admin REST API. When Fine-Grained Admin Permissions are enabled, the system fails to check for specific password reset authorizations during a general user profile update. This allows a delegated administrator, who should be restricted from resetting passwords, to change a user's credentials and take over their account.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in Keycloak represents a critical authorization bypass within the Fine-Grained Admin Permissions framework, specifically affecting the user update mechanism exposed via the Admin REST API. This flaw stems from an insufficient access control check during general profile updates. When administrators are granted specific permissions through fine-grained policies, they are expected to operate under strict least-privilege principles. However, in this scenario, the system fails to validate whether the requesting administrator possesses the explicit authorization required for password reset operations when a user's profile is being modified. This oversight allows a delegated administrator with limited privileges to inadvertently or intentionally trigger a credential change by including password fields within an otherwise standard user update request.
From a technical perspective, this issue classifies as CWE-269 Improper Privilege Management and aligns closely with ATT&CK technique T1078 Valid Accounts, specifically the sub-technique of using existing cloud accounts to gain unauthorized access. The root cause lies in the application logic that processes REST API requests for user modifications. Instead of isolating password reset operations into a distinct endpoint or enforcing granular permission checks on every field within a composite update request, Keycloak treats all fields uniformly under broader administrative privileges. Consequently, an attacker who has been granted permissions to manage basic user attributes such as email or first name can exploit this lack of segregation by appending the new_password and newPasswordConfirm parameters to their payload. The server processes these additional fields without verifying if the caller holds the specific password reset permission, thereby executing a privileged action under the guise of routine profile maintenance.
The operational impact of this vulnerability is severe, as it directly compromises account integrity and confidentiality. An attacker leveraging this flaw can take full control of any user account for which they have basic update permissions. This includes resetting passwords to values known only to the attacker, effectively locking out legitimate users and establishing persistent access. In enterprise environments where Keycloak serves as a central identity provider, such an escalation could lead to broader system compromise if those accounts hold elevated privileges or provide access to sensitive downstream applications. Furthermore, this vulnerability undermines trust in role-based access control models, potentially violating compliance requirements for strict separation of duties and auditability of administrative actions.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is to apply the official security patch provided by Keycloak maintainers as soon as it becomes available, which corrects the authorization logic in the user update endpoint. In environments where patching is not immediately feasible, administrators should restrict API access using network-level controls such as firewalls or reverse proxies that limit who can invoke Admin REST endpoints. Additionally, implementing strict input validation and field-specific permission checks at the application layer can help mitigate risk until a permanent fix is deployed. Organizations should also review their fine-grained permissions policies to ensure that delegated administrators are granted only the minimum necessary privileges, avoiding broad user management roles where possible. Regular auditing of administrative actions and enabling detailed logging for password changes can further aid in detecting any potential exploitation attempts.