CVE-2026-105207 in Zitadel
Summary
by MITRE • 10/04/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in ZITADEL versions 3.0.0 through 3.4.15 and 4.0.0 before 4.17.3 represents a critical authentication bypass flaw rooted in insufficient verification of identity ownership during account linking operations. This issue specifically affects the mechanism by which user accounts are associated with external Identity Providers, commonly referred to as IdPs such as Google, GitHub, or Microsoft Azure AD. The core technical failure lies in the application's inability to distinguish between legitimate administrative actions and unauthorized binding attempts when processing requests via the User Service V2 AddIDPLink endpoint or within identify-only Login V2 sessions. In a secure authentication flow, linking an external identity provider to an existing user account requires robust proof of ownership over both the internal ZITADEL account and the external IdP profile. However, in these affected versions, the system fails to enforce primary factor verification for the target user or validate that the requesting party possesses sufficient permissions to modify the account's linkage configuration. This architectural oversight allows an attacker who knows a victim's login name to initiate a linking process without needing prior authentication as the victim.
From an operational perspective, this vulnerability enables a severe identity takeover scenario. An unauthenticated actor can exploit the lack of verification by binding their own external IdP credentials to the target user's account within ZITADEL. Once this linkage is established, the attacker gains the ability to authenticate as the victim using the linked external provider. This effectively bypasses all native authentication mechanisms protected by passwords or multi-factor authentication configured for that specific user profile. The impact extends beyond simple unauthorized access; it compromises the integrity of identity governance and audit trails. Since the account appears legitimately accessed via a trusted third-party IdP, security monitoring systems may fail to detect the intrusion as anomalous activity. This is particularly dangerous in enterprise environments where single sign-on integrations are heavily relied upon for seamless user experience across multiple applications.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically regarding the failure to verify identity before performing sensitive actions like account modification. It also relates closely to CWE-640, Weak Password Recovery Mechanisms for Administrators and Users, as it allows an attacker to effectively reset or hijack access credentials through a linked provider rather than direct credential manipulation. In terms of the MITRE ATT&CK framework, this behavior maps to T1078 Valid Accounts, where attackers use legitimate account credentials obtained from other sources or created by them to gain initial access. Furthermore, it reflects aspects of T1562 Impair Defenses, as the attacker manipulates identity configurations to evade detection and maintain persistent access under the guise of a trusted authentication method. The specific vector involves exploiting API endpoints that handle user profile modifications without adequate session validation or permission checks against the resource owner.
Mitigation for this vulnerability requires immediate action by upgrading ZITADEL to version 4.17.3 or later, where these verification gaps have been addressed. For organizations unable to upgrade immediately due to dependency constraints, implementing strict network-level access controls on the User Service V2 endpoints can provide a temporary layer of defense. This includes restricting direct API access to known internal IP ranges and ensuring that any public-facing interfaces enforce rigorous authentication checks before processing identity linking requests. Additionally, security teams should monitor for unusual patterns in IdP linkage events, such as rapid successive binding attempts or links created from unfamiliar geographic locations. Enabling detailed audit logging focused on account modification events will aid in detecting potential exploitation attempts. It is also advisable to review existing integrations and ensure that secondary authentication factors are enforced at the application level where possible, adding a layer of defense-in-depth against identity-based attacks. Regular security assessments should include testing for improper authorization checks on user profile management APIs to prevent similar flaws from being introduced or overlooked in future updates.