CVE-2026-56666: Account Takeover via Improper Email Verification in ZITADEL Federated Identity Handler

ZITADEL is an open-source cloud-native identity management platform that provides identity federation, authentication, and authorization services. The platform is designed to handle multiple external identity providers (IdPs) via standard protocols such as OpenID Connect (OIDC) and SAML.

To simplify the authentication experience, ZITADEL includes an 'auto-linking by email' feature. This feature automatically matches and links an incoming external identity to an existing local ZITADEL account when their email addresses match, avoiding the need for manual user intervention during registration.

This vulnerability, classified as CWE-287 (Improper Authentication), arises due to a flaw in how ZITADEL validates incoming identity assertions. While ZITADEL verified that the target local account possessed a verified email status, it did not verify whether the incoming external identity provider had actually validated ownership of that email address before performing the auto-link.

The resulting impact is an authentication bypass that can lead to remote, unauthenticated account takeover. If a victim has a verified email address on a ZITADEL instance, an attacker can register that same email on a permissive external identity provider and use it to log in and automatically take control of the victim's ZITADEL account.

The core of the vulnerability lies in ZITADEL's implicit trust of the federated payload's identity claims. When a user authenticates via an external identity provider, the provider returns a payload containing user attributes. In an OIDC environment, this typically includes the email and email_verified claims.

In versions prior to 4.15.3, ZITADEL's backend logic for automatic account linking only performed validation checks on the local side of the relationship. The function checkAutoLinking checked whether the local user's email was verified in the ZITADEL database using the query NewUserVerifiedEmailSearchQuery. This check was intended to ensure that arbitrary unverified accounts could not be linked, but it failed to evaluate the security state of the incoming federated identity.

This implementation ignored the OIDC specification regarding the email_verified claim. If the external provider did not enforce email verification (a 'permissive' IdP), an attacker could register an account with a victim's email without proving ownership. Upon logging in via this IdP, the incoming payload asserted the target email address but set the email_verified attribute to false (or omitted it entirely).

Because ZITADEL skipped validating the external verification attribute, it proceeded to execute the database link. The external account was bound to the local account, establishing an authenticated session for the attacker under the victim's identity without requiring the victim's password or multi-factor authentication credentials.

The logical flaw was present in both the Go backend and the TypeScript client-side login server, requiring aligned modifications across both codebases.

In the vulnerable Go backend code within internal/api/ui/login/external_provider_handler.go, the checkAutoLinking handler did not evaluate externalUser.IsEmailVerified before processing the email search query:

// VULNERABLE Go Implementation
case domain.AutoLinkingOptionEmail:
    // Email will always be checked against verified email addresses.
    emailQuery, err := query.NewUserVerifiedEmailSearchQuery(string(externalUser.Email))
    if err != nil {
        return false, nil
    }

The patched version introduces a strict conditional check immediately prior to building the query. This prevents execution if the external user's email status is not verified:

// PATCHED Go Implementation
case domain.AutoLinkingOptionEmail:
    // When checking for email matches, we need to make sure that both (the one from the IdP and the one in Zitadel)
    // are verified to prevent potential account takeovers.
    if !externalUser.IsEmailVerified {
        return false, nil
    }
    emailQuery, err := query.NewUserVerifiedEmailSearchQuery(string(externalUser.Email))
    if err != nil {
        return false, nil
    }

A similar omission was present in the TypeScript login flow in apps/login/src/lib/server/idp-intent.ts. The server-side login logic extracted the email but bypassed checking the corresponding verification state:

// VULNERABLE TypeScript Implementation
const email = addHumanUser?.email?.email;
if (options.autoLinking === AutoLinkingOption.EMAIL && email) {
  foundUser = await listUsers({ serviceConfig, email, organizationId: organization }).then((response) => {
    return response.result ? response.result[0] : null;
  });
}

The fix introduces the emailVerified constant, which parses the OIDC verification structure and enforces that both the email and the verification assertion evaluate to true before executing the user lookup:

// PATCHED TypeScript Implementation
const email = addHumanUser?.email?.email;
const emailVerified = addHumanUser?.email?.verification?.case === "isVerified" && addHumanUser?.email?.verification?.value;
 
if (options.autoLinking === AutoLinkingOption.EMAIL && email && emailVerified) {
  foundUser = await listUsers({ serviceConfig, email, organizationId: organization }).then((response) => {
    return response.result ? response.result[0] : null;
  });
}

Exploiting CVE-2026-56666 requires specific environmental conditions but no advanced tooling or prior authentication. An attacker must identify a target ZITADEL instance that has enabled 'Auto-linking by email' and configured a permissive external identity provider.

To execute the exploit, the attacker first registers an account on the permissive external identity provider using the victim's email address (e.g., victim@company.com). Because the IdP is permissive, it does not mandate verification of the registered email address to complete the signup or issue tokens.

The attacker then navigates to the target ZITADEL instance and selects the option to authenticate via the permissive external provider. ZITADEL redirects the user to the provider, where the attacker logs in using the newly created unverified account.

Upon successful authentication, the external provider redirects back to ZITADEL, passing an identity token that asserts the victim's email. ZITADEL's vulnerable login handler reads this email, finds the matching, verified local user, and establishes the database link. The attacker's external profile is permanently associated with the victim's local identity, bypassing standard local authentication controls.

The successful exploitation of CVE-2026-56666 results in full account takeover. The attacker gains administrative or standard user permissions equivalent to the victim's local account within ZITADEL. This provides access to any downstream applications integrated with ZITADEL using single sign-on (SSO).

Although the vulnerability allows complete authentication bypass, the CVSS v3.1 score is rated as 4.8 (Medium) due to several restrictive environmental requirements. The 'Attack Complexity' (AC:H) is high because the target system must have a specific, vulnerable configuration, and there must be a permissive external identity provider linked to the environment.

No user interaction is required from the victim to trigger the compromise, making it a passive exploitation vector from the perspective of the target. Once the external account is linked, the attacker maintains persistent access even if the victim changes their local ZITADEL password, as federated authentication bypasses the local password validation checks entirely.

From a detection standpoint, the attack can be difficult to distinguish from a standard federated login unless administrators proactively audit changes to linked external identities. This makes the vulnerability highly attractive for targeted persistence in environments that utilize multiple external directory services.

The primary remediation strategy is upgrading the ZITADEL deployment to version 4.15.3 or higher. This update introduces the mandatory verification checks in both the backend and client-side logic, preventing unverified external claims from initiating automatic links.

If upgrading is not immediately possible, administrators must implement defensive mitigations to protect the environment. The most effective immediate workaround is to disable the 'Auto-linking by email' option within the Identity Provider (IdP) settings in the ZITADEL console. Administrators should transition to linking based on username (such as the OIDC sub claim) or enforce manual linking where users must log in to their local account before associating an external identity.

Administrators should also review the configuration of all configured external identity providers. Any provider that does not strictly enforce email verification before issuing OIDC tokens should be disabled or isolated.

To detect potential past exploitation, security teams should inspect ZITADEL's event store for historic linkings. Querying for user event types associated with identity provider associations (user.external.idp.added) allows security teams to identify any accounts that were linked prior to the application of the patch. These logs should be cross-referenced with external identity provider registration records to ensure correlation and legitimacy.