Summary
ZITADEL can link an attacker-controlled external identity-provider account to a victim's account without verifying a primary authentication factor or the caller's authorization. An unauthenticated attacker who knows a victim's login name may then sign in as that victim through the linked identity provider.
Affected context
The vulnerability occurs in ZITADEL account-linking workflows, including identify-only Login V2 sessions and the User Service V2 AddIDPLink endpoint. It becomes risky when these paths accept an identity-provider link request without requiring an authenticated primary factor and without confirming that the caller has permission to modify the target account.
Exploit preconditions
- Attack surface: External identity-provider account-linking flows and the User Service V2 AddIDPLink endpoint
- Required access: No authenticated account access is required; the attacker generally needs to know the victim's login name
- Trigger point: A request that associates an external IdP identity with the identified user account
- Why exploitation is possible: The linking operation does not consistently verify a primary authentication factor or authorization for the target account
Why this happens
The underlying flaw is a missing authentication and authorization check around a security-sensitive account-linking operation. The application treats user identification, such as a known login name or an identify-only session, as sufficient authority to modify account associations. This maps to CWE-306: Missing Authentication for Critical Function, because the function can change the identities permitted to access an account without establishing that the requester is authorized to perform that action.
Potential impact
- An attacker could gain access to a victim's account
- Unauthorized access to user data and account functionality could occur
- Existing authentication assurances may be bypassed through the linked external identity
- Administrative or organizational resources could be exposed if the victim has elevated privileges
- Account ownership and audit records could be undermined
General mitigation guidance
Mitigation generally focuses on treating identity-provider linking as a high-risk account-management operation rather than a user-identification step.
Common defensive patterns include:
- Require a verified primary authentication factor and an authorized account-management session before creating or changing an IdP link
- Enforce server-side authorization for the specific target account and reject identity-only sessions for security-sensitive mutations
- Require explicit user confirmation and apply reauthentication or step-up authentication where appropriate
- Use narrowly scoped endpoints and deny anonymous or ambiguous account-linking requests by default
- Apply least privilege to service identities and maintain auditable records of link creation, removal, and changes
- Notify users about new identity-provider links and provide a secure recovery and unlinking process
How teams detect issues like this
Detection and prevention can include:
- Static analysis and API review rules that flag account-linking operations lacking authentication or authorization checks
- Code review searches for identity mutations reachable from anonymous, identify-only, or pre-authentication flows
- Policy tests verifying that the target account, caller identity, primary factor, and requested operation are independently validated
- Integration tests covering unauthorized linking, cross-account targeting, and session-state transitions
- Monitoring for new IdP links created without recent primary-factor authentication, especially from unusual sources
- Automated security review tools that identify sensitive account mutations exposed through low-assurance sessions
