CVE-2026-92358 in Keycloak
Summary
by MITRE • 09/16/2026
A flaw was found in the first broker login flow of Keycloak. When a user confirms an account-linking request from a different browser, a temporary proof is created to validate the link. However, this proof is not properly cleared after the link is established or when the user later manually removes the link. An attacker who controls the external identity can exploit this leftover proof to silently re-establish the link and gain unauthorized access to the victims account without any further confirmation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Keycloak represents a critical failure in session state management within the first broker login flow, specifically concerning the mechanism used for linking user accounts across different identity providers. This flaw stems from an improper handling of temporary cryptographic proofs that are generated during the account-linking process. When a user initiates or confirms an account link between their local Keycloak account and an external identity provider, the system creates a transient proof token to validate this association. The core technical deficiency lies in the lifecycle management of this proof; rather than being invalidated immediately upon successful linkage or explicitly revoked when the user manually disconnects the accounts, these proofs persist within the server state indefinitely until they naturally expire after a long duration or are cleared through unrelated administrative actions. This persistence creates a window of opportunity for attackers to exploit stale authentication artifacts that should have been considered invalid.
From an operational perspective, this flaw allows for account takeover attacks with significant severity. An attacker who has compromised or controls the external identity provider associated with a victim can leverage these lingering proofs to silently re-establish the link between their controlled external account and the victim's Keycloak account. Because the proof is still recognized as valid by the server, the authentication flow proceeds without requiring further user interaction, such as password entry or multi-factor authentication confirmation at the point of linking. This effectively bypasses security controls designed to prevent unauthorized access during identity federation processes. The attacker gains persistent, silent access to the victim's account, potentially leading to data exfiltration, privilege escalation if linked roles allow it, and further lateral movement within environments relying on Keycloak for centralized authentication.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, as well as CWE-284, indicating improper access control where the system fails to properly restrict access to resources based on user identity or state. In terms of the MITRE ATT&CK framework, this behavior facilitates Account Manipulation techniques under Tactic TA0005, specifically allowing an adversary to establish persistence by linking their controlled external credential to a victim's account without detection. The lack of explicit revocation mechanisms means that even if a user becomes aware of the compromise and attempts to unlink the accounts through standard UI procedures, the underlying cryptographic proof remains active, rendering manual remediation ineffective until the token expires or is manually purged from backend storage by an administrator.
Mitigation strategies must focus on enforcing strict lifecycle management for these temporary proofs. The most effective immediate mitigation involves ensuring that upon successful account linking, the corresponding proof token is immediately invalidated and removed from server-side storage to prevent reuse. Similarly, when a user initiates a manual unlinking process through the Keycloak interface or API, the system must explicitly revoke any associated pending proofs related to that specific linkage attempt. Administrators should also consider implementing short-lived expiration policies for such temporary tokens as an additional layer of defense, ensuring that even if validation logic is flawed, the window of exploitability is minimized. Upgrading to patched versions of Keycloak where this state management issue has been resolved by the development team is essential for long-term security posture improvement in environments utilizing first broker login flows and account linking features.