CVE-2026-107604 in Keycloak
Summary
by MITRE • 10/08/2026
A flaw was found in the installation provider and client registration endpoints of the Keycloak identity management service. A realm administrator with only the read-only view-clients role can access the active primary secret of any confidential client, which should normally be restricted. This exposed secret can be used to impersonate the client and gain unauthorized access to its associated service account permissions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in Keycloak represents a critical authorization bypass within the identity management infrastructure, specifically targeting the installation provider and client registration endpoints. In standard security architecture for OAuth 2.0 and OpenID Connect implementations like Keycloak, confidential clients are required to maintain secret credentials that serve as proof of identity when interacting with the token endpoint or other protected resources. These secrets must be treated with strict confidentiality, accessible only by administrators who possess explicit write privileges or specific roles designed for client management. The flaw allows a realm administrator holding solely the read-only view-clients role to retrieve the active primary secret associated with any confidential client within that realm. This behavior fundamentally violates the principle of least privilege and fails to enforce proper access control checks on sensitive data retrieval operations, effectively granting low-privilege users capabilities reserved for high-privilege administrators.
From a technical perspective, this flaw stems from insufficient authorization validation in the backend logic handling requests to these specific endpoints. When an authenticated user with limited permissions issues a request to fetch client details or registration information, the system incorrectly returns the full configuration payload including the plaintext secret rather than masking it or restricting access based on role-based requirements. This misconfiguration allows attackers who have compromised low-level administrative accounts or obtained view-only credentials to extract secrets that are intended to remain hidden. The exposure of these secrets undermines the integrity of the client authentication mechanism, as the secret is a primary factor in verifying the identity of confidential clients during token exchange processes.
The operational impact of this vulnerability is severe and directly facilitates unauthorized access through credential impersonation. Once an attacker obtains the active primary secret for a specific confidential client, they can use it to authenticate as that client against Keycloak’s token endpoint. By presenting valid credentials including the stolen secret, the attacker can request access tokens scoped to the permissions assigned to that client. If the compromised client is associated with service accounts possessing elevated privileges or access to sensitive APIs and data stores, the attacker effectively inherits those rights. This enables lateral movement within the identity infrastructure, allowing the adversary to act as a trusted application rather than an end-user, thereby bypassing user-level security controls and potentially accessing resources that are not intended for public or low-privilege consumption.
This vulnerability aligns with CWE-269, which describes Improper Privilege Control, where a principal is granted privileges it should not have based on its role assignment. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques related to Credential Access and Impersonation, specifically T1078 Valid Accounts if used in conjunction with stolen credentials, or more broadly within the context of abusing application-level permissions for unauthorized access. The ability to retrieve secrets from a read-only role indicates a failure in implementing robust object-level authorization checks, which is a common pitfall in complex identity management systems where multiple roles interact with shared resources like client configurations.
Mitigation strategies must focus on immediate remediation and long-term architectural hardening. Administrators should apply the latest security patches provided by Keycloak vendors to address this specific access control flaw immediately. In environments where patching is delayed, network-level controls such as firewalls or API gateways can be configured to restrict access to client registration endpoints based on IP addresses associated with trusted administrative workstations rather than relying solely on application-layer authentication. Additionally, organizations should audit their realm configurations to ensure that the view-clients role does not inadvertently include permissions for sensitive data retrieval and consider implementing additional monitoring alerts for unusual requests to these endpoints from low-privilege accounts. Regular rotation of client secrets is also recommended as a defense-in-depth measure, although it does not replace the need for fixing the underlying authorization logic.