Description

ZITADEL 3.0.0 through 3.4.15 and 4.0.0 before 4.17.3 creates links between user accounts and external identity providers without verifying a primary factor or the caller's permission, including on identify-only Login V2 sessions and via the User Service V2 AddIDPLink endpoint. An unauthenticated attacker knowing a victim's login name can bind their own external IdP identity to the victim's account and then sign in as the victim.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-04T15:16:31.677Z",
  "pubdate": "2026-10-04T15:16:31.677Z",
  "executiveSummary": "ZITADEL versions 3.0.0 through 3.4.15 and 4.0.0 through 4.17.2 contain a critical improper authorization vulnerability within the identity provider (IdP) linking mechanism.\nThe flaw resides in the handling of account linkages where the system fails to verify primary authentication factors or check for proper authorization from the caller during the linking process.\nThis vulnerability allows an unauthenticated attacker, provided they possess a victim's login name, to associate their own external IdP identity with the target user's account.\nBy successfully binding their malicious IdP to a victim's account, an attacker can bypass standard authentication controls and achieve unauthorized account access, effectively facilitating full account takeover.\nThe issue affects the Login V2 flow and the User Service V2 AddIDPLink endpoint, presenting a significant security risk for environments relying on ZITADEL for centralized identity management.\nThe exploitation does not require administrative privileges or previous authentication, as the missing validation allows for anonymous request submission.",
  "technicalDetails": "The root cause of this vulnerability is the lack of mandatory identity verification during the IdP linkage process in ZITADEL. Specifically, the system processes linkage requests via the User Service V2 AddIDPLink endpoint and Login V2 sessions without enforcing that the requester has established a valid primary authentication session or has the necessary authorization to modify the target user account.\nThe attack flow begins when an attacker identifies the login name of a target user. Because the application logic fails to validate the caller's authority to link an IdP, the attacker can initiate an AddIDPLink request targeting the victim's account identifier.\nBy leveraging an external IdP account under their control, the attacker presents this identity to the vulnerable ZITADEL endpoint. The server, failing to verify that the person initiating the linkage is the owner of the target account or possesses administrative rights, processes the request and updates the internal mapping table to associate the attacker's IdP identity with the victim's local ZITADEL account record.\nOnce the mapping is persisted in the database, the attacker can trigger an authentication flow using their external IdP. Upon successful login via the attacker-controlled IdP, the ZITADEL engine checks the established links, identifies the match with the victim's account, and authenticates the attacker as the victim.\nThis vulnerability effectively bypasses multi-factor authentication (MFA) and standard credential checks, as the external IdP becomes a trusted primary authentication method for the victim's account through the forged link.\nThe issue is widespread across the identified versions 3.0.0-3.4.15 and 4.0.0-4.17.2, specifically impacting the logic governing the User Service V2 API and the automated Login V2 workflows. The failure to require a session context or a proof-of-possession mechanism for the account owner facilitates trivial exploitation by any network-adjacent or remote attacker who can interact with these ZITADEL endpoints."
}