zitadel

ZITADEL's ten flaws: how a self-hosted identity provider let anyone sign in as anyone

NVD cataloged ten authentication and authorization flaws in ZITADEL, the open-source identity provider, on 2026-10-04. The shared shape is a login flow that treated "knowing a username" as if it were "proving a password." The fixes shipped in three waves over the prior two months.

Glenn Fryklund

Glenn Fryklund

— 4 min read
Share
ZITADEL's ten flaws: how a self-hosted identity provider let anyone sign in as anyone
A self-hosted identity provider server whose lock is bypassed by a thin red thread that binds an attacker's external identity to a victim's account, the shared shape of the ten ZITADEL authentication flaws.

On a single self-hosted identity server, an attacker who only knows your username could sign in as you. That is the shared shape of ten flaws in ZITADEL, the open-source identity and access management server, that NVD cataloged on 2026-10-04. Three carry a CVSS of 9.3, one is 9.2, four are HIGH, and two are lower (a 5.3 and a 2.3 server-side request forgery). None of the sources retrieved for this piece assert in-the-wild exploitation, and none of these CVEs appear in CISA's Known Exploited Vulnerabilities list.

The cataloging date

The cataloging date is worth separating from the event dates. ZITADEL's own GitHub Security Advisories were published earlier, spanning 2026-07-29 through 2026-09-28, and the fixes shipped in three waves: 4.16.2 and 3.4.14 on 2026-07-29, 4.17.1 and 3.4.15 on 2026-08-14, and 4.17.3 on 2026-09-04. The NVD batch on 2026-10-04 is the cataloging event, not the discovery.

The trust-model error

Most of the flaws share one root cause, and it is a trust-model error rather than a single bad line. ZITADEL's Login V1 and V2 flows let a client reach a state we can call identify-only: the server has confirmed the caller knows a valid login name, but has not yet verified a primary factor such as a password or an MFA code. Several of the flaws let a privileged action run in that identify-only state, before the primary factor is checked.

Take CVE-2026-105211 (9.2). An unauthenticated attacker who knows a victim's login name can read the victim's OTP-Email and OTP-SMS codes from server-action responses, because the OTP delivery type returns the code in the response. From there the attacker obtains a session that has already passed MFA, including administrator takeover. CVE-2026-105210 (8.8) and CVE-2026-105212 (8.7) are the same idea in the second-factor enrollment handlers: an attacker knowing only a login name can register an attacker-controlled TOTP, OTP-SMS, OTP-Email, U2F, or passkey factor, overwriting the victim's verified phone number, and then sign in as the victim.

The cross-organization flaw is the one that breaks the boundary that makes a self-hosted provider useful. CVE-2026-105209 (9.3) issues passkey and passwordless enrollment codes using only the organization in the x-zitadel-orgid header, not the target user's actual organization. A user with write permission in one organization can mint an enrollment code for a user in another organization on the same instance, register their own authenticator, and take over that account. If you run one ZITADEL instance for many teams, that is the isolation boundary failing.

The IdP-linking flaws add a second route to the same end. CVE-2026-105207 (9.3) creates links between user accounts and external identity providers without verifying a primary factor or the caller's permission, including on identify-only sessions and via the User Service V2 AddIDPLink endpoint. An unauthenticated attacker who knows a victim's login name binds their own external identity to the victim's account and signs in as the victim. CVE-2026-105215 (9.3) is the Login V1 variant: the "external account not found" registration endpoint trusts client-supplied external identity fields without a completed IdP callback, so an attacker pre-creates an account bound to the victim's external identity. When the victim later logs in for real, they land in the attacker's account.

The takeaway

The takeaway for operators is not "patch ten bugs." It is that these ten CVEs are one trust-model problem remediated in stages, which is why the fix cascaded across five versions over six weeks. If you run ZITADEL, the defensive response is concrete: upgrade to 4.17.3 (or 3.4.15 on the 3.x line), then review any external identity provider manual-linking configuration and any enrollment flows that let a client act before a primary factor is verified.

For the self-hosted crowd, the relevance is direct. ZITADEL is a common choice for teams that want to own their identity stack rather than rent it. A login flow that conflates "identified" with "authenticated" is exactly the kind of flaw that is hard to notice in a single-tenant homelab and dangerous in a multi-team deployment. The cluster is a reminder that the identity server's login flow is the highest-trust surface you own, and that a single trust-model error can fan out into a dozen CVEs.

Sources

Transparency note: This article was drafted with the assistance of a large language model (Qwen3.6-35B-A3B, running locally on the R9700 via the local LiteLLM proxy) and reviewed by the Malwlab editorial team. All technical claims are sourced to the named public records above; the model did not introduce any unsourced technical facts. The feature image was rendered locally via ComfyUI (SDXL) on the 5060ti-a deployment.
Topics:

Read more