CVE-2026-105215: ZITADEL Account Pre-Hijacking via Forged External IdP Callback

Overview

A critical authentication flaw has been disclosed in ZITADEL, the open-source identity and access management (IAM) platform used to centralize login, SSO, and user management for web and mobile applications. Tracked as CVE-2026-105215 with a CVSS 3.1 score of 9.1 (9.3 on CVSS 4.0), the flaw lives in ZITADEL's hosted Login V1 UI and lets an unauthenticated attacker pre-create a user account bound to an arbitrary external identity provider (IdP) identity — without ever completing a real login at that IdP.

The root cause is that the "external account not found" registration endpoint, which fires when a user attempts to sign in via an external IdP for the first time, trusts client-supplied IDPConfigID and ExternalUserID values at face value instead of requiring a verified, completed IdP callback. An attacker who knows or guesses a victim's external user ID (for example, a GitHub numeric user ID or an email tied to a social login) can forge those fields to register the account first. When the real victim later signs in legitimately through that same external IdP, ZITADEL matches them straight into the attacker's pre-created account.

Technical Details

How It Works

ZITADEL's hosted Login V1 UI supports "Sign in with..." flows against external identity providers (Google, GitHub, Azure AD, generic OIDC/SAML, etc.). When a user authenticates via an external IdP for the first time and no matching local account exists, ZITADEL routes them to a registration step — the "external account not found" endpoint — which is supposed to create a new local account linked to the identity the IdP just verified.

The flaw is that this endpoint accepted the IDPConfigID and ExternalUserID values directly from the client-supplied registration form body, rather than pulling verified identity data from a completed, cryptographically-backed IdP callback (what the fix now calls authReq.LinkingUsers). Because those two fields are frequently guessable or publicly known — many IdPs expose a stable numeric or email-based external user ID — an attacker could submit a forged registration request claiming to be "pre-authenticated" against a victim's known external identity, without the IdP ever being involved.

This only works against IdP configurations that allow manual account creation (the self-service flow where a new user reviews/edits their profile before the account is created). Automatic account creation is unaffected, because it only runs after a genuine, verified IdP callback and reads external user data server-side rather than from the registration form. If an IdP has both manual and automatic creation enabled, the manual path remains exploitable. Critically, Login V2 is not affected at all — it binds the IdP "intent" cryptographically and never trusts client-supplied identity fields at this stage.

Once the forged account exists, the attack completes itself passively: the next time the real victim clicks "Sign in with <provider>" and completes a genuine, legitimate authentication at that IdP, ZITADEL's matching logic resolves them into the attacker's pre-created account — handing the attacker a live, authenticated session as the victim with no further action required.

Impact Assessment

Who Is At Risk

Any organization running a self-hosted ZITADEL instance in the affected ranges (3.0.0 through 3.4.13, or 4.0.0 through 4.16.1) is exposed if it:

• Uses ZITADEL's hosted Login V1 UI (Login V2 deployments are not affected)
• Has at least one external IdP configured with "Account creation allowed (manually)" enabled
• Exposes that Login V1 flow to the public internet, where attackers can enumerate or guess victims' external IdP identities

This is a pre-positioning attack rather than an instant breach: the attacker must forge the registration before the victim's first genuine login via that IdP. Organizations that provisioned ZITADEL recently, are mid-rollout of a new external IdP, or have high-value users (administrators, executives) who haven't yet completed their first SSO login are the most exposed.

Potential Attack Chains

1. Identity Reconnaissance — Attacker identifies a target's external IdP identity (a GitHub numeric user ID, a known email tied to Google/Microsoft login, etc.) via OSINT or public profile data
2. Forged Pre-Registration — Attacker submits a crafted request to the "external account not found" registration endpoint with the victim's ExternalUserID and the target IDPConfigID, with no IdP callback ever occurring
3. Account Materializes — ZITADEL creates a local account bound to the forged external identity, believing it to be the victim's future account
4. Passive Takeover — The real victim later signs in legitimately through the same external IdP; ZITADEL matches them into the attacker-controlled account, and the attacker now shares (or exclusively holds) access to that identity and everything it's entitled to

Because ZITADEL is commonly deployed as the central IAM layer across an organization's application portfolio, a pre-hijacked account can grant the attacker a foothold across every downstream service that trusts ZITADEL-issued sessions for that user.

Mitigation

Immediate Actions

• Upgrade immediately to ZITADEL 4.16.2 (4.x branch) or 3.4.14 (3.x branch), which require a verified, completed IdP callback before creating an account and no longer trust identity/verification flags from the registration form body
• Note the 3.x end-of-life: the 3.x release line reached end-of-life on 2026-08-31 and will receive no further security patches beyond 3.4.14 — organizations still on 3.x should treat migration to the 4.x branch as a priority, not just the point patch
• If an immediate upgrade isn't possible, disable "Account creation allowed (manually)" on every configured external IdP; this closes the vulnerable path but also disables legitimate self-service account creation via that IdP
• Audit recently created accounts — especially ones created via external IdP registration shortly before a user's first genuine SSO login — for signs of pre-hijacking
• Consider enabling automatic account creation with manual creation disabled as an interim mitigation; this changes onboarding (accounts are created immediately after a verified IdP login, without a review/edit step) but avoids the vulnerable registration path entirely

Detection Opportunities

• Query ZITADEL audit/event logs for external-account registrations where the registration event precedes any verified IdP callback event for that user
• Look for registration requests presenting IDPConfigID/ExternalUserID pairs that don't correlate with a corresponding completed IdP authentication in your IdP's own logs
• Monitor for accounts that sit "dormant" after creation via external IdP registration, then suddenly become active once a real user's first SSO login occurs — a signature of the pre-hijack-then-wait pattern

Defence-in-Depth

• Prefer Login V2 where feasible — it binds the IdP intent cryptographically and is not affected by this registration path
• Enforce multi-factor authentication on sensitive and administrative accounts to limit the blast radius if an identity is pre-hijacked
• Restrict exposure of Login V1 external-registration flows to the minimum necessary audience, and rate-limit registration attempts against the "external account not found" endpoint
• Regularly review which external IdPs have manual account creation enabled, and disable it for any IdP that doesn't genuinely need self-service onboarding

Discovery & Disclosure

The vulnerability was reported by Michael Wollner of Deutsche Telekom AG and Adam Korczynski of Ada Logics (with assistance from Anthropic). It is tracked upstream in ZITADEL's own repository advisory GHSA-738m-7888-jfv8 (published 2026-07-29) and mirrored as the public CVE record GHSA-639g-x9rp-hw3x / CVE-2026-105215. As of publication, CVE-2026-105215 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog and no public proof-of-concept exploit has been observed — but given the unauthenticated, zero-interaction attack path and the now-unsupported 3.x branch, defenders should treat patching as urgent rather than wait for confirmed in-the-wild exploitation.

References

• NVD — CVE-2026-105215
• GitHub Security Advisory — GHSA-738m-7888-jfv8
• GitHub Advisory Database — GHSA-639g-x9rp-hw3x
• Strix — CVE-2026-105215: Authentication Bypass
• TheHackerWire — ZITADEL IdP Authentication Bypass Leads to Account Forgery
• VulnCheck Advisory — ZITADEL before 4.16.2 Account Pre-Hijacking via Forged External IdP Callback