CVE-2026-94215 in Keycloak
Summary
by MITRE • 09/21/2026
A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The issue occurs because the API uses a per-request in-memory cache to resolve clients by their unique identifier without verifying if the client belongs to the realm specified in the request path. This allows an administrator with limited privileges to read or modify sensitive client configurations in the master realm by accessing them through a realm they control. Successful exploitation could lead to the exposure of client credentials or the redirection of administrative login attempts to malicious sites.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified within Keycloak represents a critical authorization bypass stemming from improper implementation of access controls on its Admin REST API, specifically concerning how clients are resolved and validated against their associated realms. In standard identity and access management architectures, strict isolation between tenants or realms is paramount to ensure that administrative actions performed in one context do not inadvertently affect resources in another. However, the flaw arises because the API utilizes a per-request in-memory cache for resolving client entities by their unique identifiers without performing an additional verification step to confirm that the resolved client actually belongs to the realm specified in the request path parameters. This architectural oversight creates a scenario where the system trusts the identifier provided in the request body or query string more than it validates the contextual boundary defined by the URL path, effectively decoupling resource identification from access control enforcement.
From an operational perspective, this technical flaw allows an administrator with limited privileges within any non-master realm to interact directly with clients residing in the master realm. By crafting specific API requests that target client identifiers belonging to the privileged master realm while authenticating as a lower-privileged user in their own controlled realm, attackers can bypass standard permission checks. The lack of cross-realm validation means that once the system locates the client object via its ID, it proceeds with the requested operation without ensuring that the requesting principal has explicit authorization for resources outside their designated tenant boundary. This breaks the fundamental principle of least privilege and multi-tenancy security models inherent in modern IAM solutions like Keycloak.
The impact of this vulnerability is severe due to the high level of access typically granted to administrators within a realm, particularly when those actions affect the master realm which often controls global configurations, authentication flows, and client definitions for all other realms. Successful exploitation enables an attacker with limited privileges to read sensitive configuration data from the master realm, including potentially exposing client credentials such as secrets or keys that are critical for securing API integrations and service-to-service communications. Furthermore, by modifying these high-privilege clients, an adversary can alter redirect URIs or authentication settings, facilitating phishing attacks where administrative login attempts are redirected to malicious sites controlled by the attacker. This could lead to credential harvesting, session hijacking, or further lateral movement within the identity infrastructure.
This issue aligns with CWE-269 Improper Privilege Management and CWE-807 Reliance on Untrusted Inputs in a Security Context, as it involves failing to enforce proper access control checks based on user roles and resource ownership. In terms of MITRE ATT&CK mapping, this vulnerability facilitates the Initial Access and Persistence tactics by allowing an attacker with low-level credentials to escalate their influence over critical identity resources without detection through standard audit logs that might only show legitimate-looking API calls from authorized users. The exploitation relies on abusing trusted administrative interfaces rather than exploiting a code execution flaw, highlighting the importance of rigorous input validation and context-aware authorization checks in web APIs.
Mitigation strategies must focus on enforcing strict realm isolation at the point of resource resolution within the Admin REST API logic. Developers should implement explicit verification steps that compare the realm ID associated with the requested client against the realm ID specified in the request path or derived from the authenticated user's session context, rejecting any mismatch immediately. Additionally, caching mechanisms for sensitive resources like clients and roles should be scoped strictly to their respective realms to prevent cross-tenant data leakage through shared memory structures. For organizations currently running affected versions of Keycloak, upgrading to a patched version that includes these authorization fixes is essential. In the interim, network-level controls such as restricting access to the Admin API endpoints to only those IP addresses or service accounts with verified high privileges can provide an additional layer of defense against exploitation attempts targeting this specific privilege escalation vector.