CVE-2026-15571 in Keycloak
Summary
by MITRE • 08/19/2026
A flaw was found in the legacy client-initiated account-linking endpoint of Keycloak, a widely used open-source identity and access management solution. The mechanism used to protect the account-linking process from unauthorized requests relies on a hash that can be predicted by a malicious OIDC client. By tricking a user into authenticating, an attacker-controlled client can forge a valid linking URL to connect the victim's account to an attacker's external identity. This results in a full account takeover, allowing the attacker to log in as the victim.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified within Keycloak represents a critical failure in the security design of its legacy client-initiated account-linking mechanism. Keycloak is a widely deployed open-source identity and access management solution that handles authentication for numerous enterprise applications, making any flaw in its core linking logic potentially catastrophic. The specific weakness resides in how the system validates requests to link an existing user account with an external OpenID Connect provider. This process relies on a cryptographic hash intended to prevent Cross-Site Request Forgery attacks by ensuring that only legitimate users can initiate or confirm such sensitive operations. However, the implementation of this protective measure is flawed because the generated token or hash lacks sufficient entropy and predictability constraints. An attacker possessing control over an OIDC client registered within Keycloak can reverse-engineer or brute-force the generation algorithm to produce valid linking tokens without requiring the victim's immediate interaction beyond initial authentication.
From a technical perspective, the flaw exploits the deterministic nature of the link token generation process when specific parameters are manipulated by an authorized but malicious client application. The system assumes that because the request originates from a registered OIDC client with valid credentials, it is trustworthy. It fails to adequately verify that the user explicitly consented to linking their account to this specific external identity provider in real-time. By tricking a victim into authenticating through the attacker-controlled client, the adversary can capture or predict the session state and generate a forged link URL. This URL contains a valid cryptographic signature that Keycloak accepts as proof of authorization. Consequently, the system proceeds to bind the victim's local account credentials to the attacker's external identity provider without requiring additional confirmation steps such as re-authentication or explicit consent dialogs for the linking action itself.
The operational impact of this vulnerability is severe and equates to a full account takeover. Once the link is established, the attacker gains the ability to authenticate as the victim using their own OIDC credentials through the external identity provider. This bypasses traditional password-based authentication controls entirely. In environments where multi-factor authentication or complex passwords are enforced for direct login, this flaw effectively neutralizes those protections because the entry point shifts from the primary application's credential store to the linked external account. An attacker can maintain persistent access even if the victim changes their local password, as long as they retain control over the linked OIDC identity. This undermines the fundamental trust model of single sign-on architectures and compromises data confidentiality and integrity for all applications relying on Keycloak for authentication.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically in the context of insufficient verification of user intent during sensitive state changes. It also relates to CWE-345, Insufficient Verification of Data Authenticity, as the system accepts a forged token that appears valid due to weak cryptographic assumptions. In terms of MITRE ATT&CK framework tactics, this flaw facilitates Account Manipulation and Initial Access techniques where an adversary leverages trusted relationships within identity infrastructure to establish persistence or escalate privileges without detection by standard monitoring tools designed for brute-force or credential stuffing attacks.
Mitigation strategies must address both the immediate technical weakness and broader architectural assumptions. Organizations using Keycloak should immediately upgrade to a version that includes patches addressing this specific account-linking validation logic, ensuring that link tokens are generated with high-entropy random values tied strictly to short-lived sessions rather than predictable patterns. Administrators should disable legacy client-initiated linking endpoints if they are not explicitly required by their application stack, opting instead for server-side flow implementations where the identity provider has more control over the consent process. Furthermore, implementing strict redirect URI validation and enforcing explicit user consent screens that clearly indicate when an account is being linked to a third-party service can provide necessary defense-in-depth layers. Regular auditing of registered OIDC clients and monitoring for unusual linking activities are also recommended to detect potential exploitation attempts in real-time.