CVE-2026-105209: ZITADEL Cross-Organization Account Takeover via Passkey Enrollment

Overview

A critical authorization flaw has been disclosed in ZITADEL, the open-source identity and access management (IAM) platform used to run multi-tenant single sign-on for internal and customer-facing applications. Tracked as CVE-2026-105209 with a CVSS v3.1 score of 9.6 (CVSS v4.0: 9.3), the vulnerability lets an attacker who holds ordinary user-write permission in any one organization on a shared ZITADEL instance enroll a passkey or passwordless credential against a user account that belongs to a completely different organization — and then log in as that user.

The root cause is in how ZITADEL issues passkey and passwordless enrollment codes: the authorization check validates the caller's permission against the organization named in the x-zitadel-orgid request header, but never confirms that the target user actually belongs to that same organization. On any instance hosting multiple organizations — a common pattern for MSPs, SaaS platforms, and enterprises that delegate self-service org administration — this collapses the tenant boundary between organizations.

Technical Details

How It Works

ZITADEL is built around a multi-tenant "organization" model: a single instance can host many isolated organizations, each with its own users and its own set of principals holding roles such as user-write (the permission needed to manage accounts, including registering authentication factors on a user's behalf).

When a caller requests a passkey or passwordless enrollment code for a user, ZITADEL authorizes the request by checking whether the caller has user-write permission in the organization identified by the x-zitadel-orgid request header. That check stops there — it never verifies that the userId supplied in the same request actually belongs to the organization named in that header.

In practice, this means an attacker only needs user-write permission in any organization on the instance, including a low-trust organization they created or control themselves. By setting x-zitadel-orgid to their own organization while supplying a victim's userId from an entirely different organization, the attacker receives a valid enrollment code scoped to the victim's account. Completing the WebAuthn registration ceremony with that code binds an attacker-controlled authenticator — a hardware key, platform passkey, or passwordless credential — directly to the victim's account. From that point, the attacker authenticates as the victim with their own device. No password is guessed, no victim action is required, and no permission over the victim's organization was ever granted.

Impact Assessment

Who Is At Risk

Any organization running a self-hosted, multi-organization ZITADEL instance in the affected version ranges (3.0.0 through 3.4.14, or 4.0.0 through 4.17.0) is exposed, particularly deployments that:

• Host multiple customer, partner, or business-unit organizations on a single shared ZITADEL instance (a common MSP/SaaS pattern)
• Delegate self-service organization creation or org-admin roles broadly, including to lower-trust or externally-facing tenants
• Use passkeys or passwordless authentication as a primary or step-up factor for privileged accounts
• Expose the Management/User Service APIs used to issue enrollment codes beyond a tightly controlled admin network

Potential Attack Chains

1. Foothold Acquisition — Attacker obtains or self-registers an account with user-write permission in any organization on the shared instance (their own tenant, a trial org, or a compromised low-privilege admin credential)
2. Target Identification — Attacker identifies a victim's userId in a different, higher-value organization on the same instance (via enumeration, prior reconnaissance, or a leaked identifier)
3. Cross-Org Enrollment Request — Attacker calls the enrollment-code endpoint with x-zitadel-orgid set to their own organization but the victim's userId as the target
4. Credential Binding — ZITADEL issues a valid enrollment code; the attacker completes the WebAuthn ceremony, registering their own authenticator on the victim's account
5. Takeover — Attacker signs in as the victim using the newly enrolled passkey, inheriting that account's full permissions on the instance and every downstream application relying on ZITADEL for SSO

Because a single ZITADEL instance frequently backs authentication for many unrelated applications and tenants, a foothold as small as self-service signup in one low-trust organization can cascade into takeover of accounts — including administrators — in any other organization on the same instance.

Mitigation

Immediate Actions

• Upgrade immediately to ZITADEL 4.17.1 (4.x branch) or 3.4.15 (3.x branch), which enforce that the target user's organization matches the authorized organization before issuing enrollment codes
• Audit all passkey and passwordless credentials registered across every organization on the instance, focusing on enrollments that don't correlate with a known admin action or self-service flow
• Revoke and remove any authenticator discovered during the audit that cannot be attributed to the legitimate account owner
• Review which principals hold user-write permission on the instance and in which organizations — treat any low-trust or self-service organization's admins as a potential pivot point until patched
• The upstream advisory notes there is no configuration workaround that fully mitigates this on an unpatched instance — treat patching as the only complete fix

Detection Opportunities

• Query ZITADEL audit/event logs for enrollment-code issuance events where the x-zitadel-orgid header's organization does not match the target user's actual organization
• Flag passkey/passwordless registrations followed shortly by a login from a new device or IP inconsistent with the account owner's normal pattern
• Monitor for a single principal issuing enrollment codes for users across multiple different organizations in a short time window — a strong signal of automated exploitation
• Review recent additions to privileged/admin accounts' registered authenticators specifically

Defence-in-Depth

• Enforce strict tenant isolation reviews for any multi-organization ZITADEL deployment — treat cross-org API calls as a standing threat model, not an edge case
• Apply least privilege to user-write role assignments; avoid granting it broadly to self-service or externally-controlled organizations
• Require step-up verification (e.g., re-authentication or admin approval) before binding a new authenticator to an existing account, independent of this specific flaw
• Periodically review and prune registered passkeys/authenticators on all accounts, especially privileged ones

Discovery & Disclosure

CVE-2026-105209 was disclosed via ZITADEL's GitHub Security Advisory process as GHSA-pq2q-2c6r-75c4, reported by contributors rud, rz1027, lyhtheori, and AdamKorcz, with the fix developed by IAM-marco and reviewed by grvijayan. It was published alongside a broader cluster of ZITADEL authentication and authorization vulnerabilities disclosed the same day, including the unrelated unauthenticated IdP-linking account takeover tracked as CVE-2026-105207. As of publication, CVE-2026-105209 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, no public proof-of-concept exploit has been identified, and its EPSS score has not yet been assigned. Given the low privilege bar and zero victim interaction required, defenders should prioritize patching rather than wait for confirmed in-the-wild exploitation.

References

• NVD — CVE-2026-105209
• Strix — CVE-2026-105209: Missing Authorization Vulnerability
• TheHackerWire — CVE-2026-105209: ZITADEL Improper Authorization Enables Cross-Organization Account Takeover
• ZITADEL Security Advisory — GHSA-pq2q-2c6r-75c4