Description

A flaw was found in the first-broker-login flow of the Keycloak identity management service. When a user links a social identity provider account to their local account, the verification proof generated is not strictly bound to the specific upstream identity being verified. This allows an attacker with a different account on the same social provider to intercept the process and link their own account to the victim's local profile, gaining unauthorized access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-02T02:17:19.750Z",
  "pubdate": "2026-09-02T02:17:19.750Z",
  "executiveSummary": "This vulnerability involves a flaw in the first-broker-login flow of the Keycloak identity management service, specifically concerning the association of social identity provider accounts with local user profiles.\nThe issue stems from a lack of strict binding between the verification proof and the specific upstream identity, categorized as an improper authentication or session management weakness.\nAn attacker can exploit this discrepancy to perform an account linking attack, where a victim's local account is inadvertently associated with an attacker-controlled social identity.\nThe potential impact includes unauthorized access to the victim's local Keycloak account, potentially leading to full account takeover or unauthorized data access.\nExploitation requires the attacker to possess an account on the same social identity provider and the ability to intercept or influence the identity linking process initiated by the victim.\nThis flaw represents a significant risk to organizations utilizing Keycloak's social login federation, as it undermines the integrity of the account binding process.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient validation of the authentication assertion during the 'first-broker-login' flow in Keycloak. When a user attempts to link an external social identity provider (IdP) account to an existing local identity, the service generates a verification proof to confirm the legitimacy of the external authentication.\nIn the vulnerable implementation, this proof is not cryptographically or logically bound to the specific identity (e.g., unique identifier or email) returned by the upstream IdP. Consequently, the service fails to verify that the identity being linked is the exact one that initiated the original request.\nThe attack flow proceeds as follows: 1) The victim initiates the account linking process, redirected to the social IdP; 2) The attacker intercepts or identifies the state of this ongoing authentication flow; 3) The attacker triggers their own authentication process with the same social IdP provider; 4) Due to the lack of strict binding, the attacker forces the Keycloak service to associate their controlled social identity with the victim's local account profile.\nThe vulnerability occurs within the identity brokering component responsible for handling the handoff between external IdP assertions and the local session state. Because the system does not enforce a rigid correlation between the transient authentication session and the specific user context, the backend application accepts the attacker's assertion as valid for the victim's ongoing session.\nThis exploit bypasses standard account linking protections, effectively allowing an attacker to 'hijack' the association. Once the attacker's IdP account is linked, they can authenticate as the victim by logging in through the social IdP, as the platform now recognizes the attacker's credentials as an authorized method to access the victim's profile.\nThis vulnerability is particularly critical as it does not require access to the victim's credentials, only the ability to manipulate the browser-based flow during the redirect handoff. The attack is effective in any deployment where multiple users utilize the same social identity provider for Keycloak authentication."
}