CVE-2026-118947 in Keycloak
Summary
by MITRE • 10/30/2026
A flaw was found in the UMA resource registration endpoint of the keycloak-services component, which provides the core logic for Keycloak's authorization and identity services. The issue occurs when remote resource management is enabled, allowing an authenticated user with specific permissions to update resources they do not own by providing a target resource ID in a request. This can lead to unauthorized modification of resource configurations, such as names, URIs, and scopes.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within the Keycloak-services component specifically targets the User-Managed Access UMA resource registration endpoint, representing a critical failure in access control logic for identity and authorization services. Keycloak serves as an open-source Identity and Access Management solution widely deployed to secure applications and microservices by managing user identities, authentication protocols such as OAuth 2.0 and OpenID Connect, and fine-grained authorization policies. The core flaw resides in the mechanism that handles resource registration updates when remote resource management is enabled. In a properly secured system, an authenticated entity should only be able to modify resources explicitly owned or assigned to them by the administrator. However, due to insufficient validation of ownership during update operations, the application fails to verify whether the requesting user holds legitimate administrative rights over the specific resource identified in the request payload.
Technically, this flaw manifests as a Broken Access Control vulnerability where the server accepts and processes requests containing a target resource ID without adequately cross-referencing that identifier against the identity of the authenticated session initiating the request. An attacker who has obtained valid credentials for an account with basic permissions can exploit this by crafting HTTP requests to update arbitrary resources within the realm. By manipulating the resource ID field in the request body, the adversary can bypass ownership checks and alter configurations belonging to other users or administrative entities. This includes modifying critical attributes such as resource names, Uniform Resource Identifiers URIs, and associated scopes which define what actions are permitted on those resources. The absence of strict object-level authorization allows for a direct violation of integrity controls within the identity infrastructure.
The operational impact of this vulnerability is severe given the central role Keycloak plays in enterprise security architectures. Unauthorized modification of resource configurations can lead to significant disruptions in service availability and data confidentiality. For instance, an attacker could alter URIs associated with sensitive resources, potentially redirecting authentication flows or causing application failures for legitimate users relying on those endpoints. Furthermore, modifying scopes may grant unauthorized access levels to other entities, effectively escalating privileges across the system. This undermines the trust model of the entire authorization framework, as clients and services rely on Keycloak to enforce strict boundaries between different user roles and resource permissions. The ability to change these configurations without proper oversight can facilitate further attacks such as privilege escalation or lateral movement within a compromised environment.
This issue aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, which describe scenarios where an actor is able to perform actions beyond their intended permissions due to flawed logic in access control mechanisms. From the perspective of the MITRE ATT&CK framework, this vulnerability facilitates techniques related to Account Manipulation and potentially Defense Evasion if used to alter logging or monitoring configurations associated with resources. It also touches upon Path Traversal concepts indirectly by allowing manipulation of resource identifiers that map to internal system objects. The exploitation requires an authenticated user but does not necessarily require high-level administrative privileges initially, making it accessible to a broader range of potential adversaries who may have compromised lower-privileged accounts through phishing or credential stuffing attacks.
Mitigation strategies must focus on enforcing strict object-level access controls within the Keycloak-services component. Developers should implement robust validation logic that verifies the ownership relationship between the authenticated user and the resource being modified before processing any update requests. This involves querying the database to confirm that the requesting session's principal ID matches the owner field of the target resource record. Additionally, implementing role-based checks ensures that only users with specific administrative roles can modify resources they do not own, adhering to the principle of least privilege. For organizations currently running vulnerable versions, applying vendor-provided patches is the primary remediation step. Until updates are applied, administrators should consider disabling remote resource management if it is not strictly required for their deployment model, thereby removing the attack surface associated with this endpoint. Regular auditing of access control policies and monitoring for anomalous modification patterns can also help detect exploitation attempts early in an intrusion lifecycle.