A serious account-takeover vulnerability has been disclosed in ZITADEL, the open-source identity platform. CVE-2026-105207 affects ZITADEL versions 3.0.0 through 3.4.15 and 4.0.0 before 4.17.3. If you're running either branch unpatched, an attacker who knows nothing but a target's login name can fully take over that account.

Here's the core failure: ZITADEL's Login V2 identify-only sessions and the User Service V2 AddIDPLink endpoint both allow external identity provider links to be created without completing a primary factor challenge or verifying the caller has permission to touch that account. No password, no MFA, no session token. An attacker registers a throwaway identity with a supported external IdP, calls the endpoint with the victim's login name, binds that IdP identity to the victim's account, and then signs in as them using that linked credential. That's a complete authentication bypass using the federation mechanism itself as the attack path.

What makes this particularly uncomfortable is that external IdP linking is supposed to be a convenience feature for legitimate users. The assumption baked into its design was that only an authenticated, authorized session could trigger a link. That assumption was wrong, and the consequences are as bad as they get: account takeover without any credential knowledge. If your ZITADEL deployment has user-facing federation enabled and is reachable from untrusted networks, you should treat every account on it as potentially at risk until you patch.

For anyone running ZITADEL in a CIAM or internal IdP capacity, the Monday morning question is straightforward: what version are you on? Upgrade to 3.x (check ZITADEL's release notes for the fixed 3.x version) or 4.17.3 or later immediately. If you can't patch right now, look at whether you can restrict access to the AddIDPLink API endpoint at the network or gateway layer as a temporary control. Also pull your IdP link audit logs for any accounts that recently had an external IdP added, especially if the linking event doesn't correspond to a known user action. You're looking for anomalous link creation events on accounts that weren't actively managed at that time.

The honest caveat: I don't know from the disclosure whether ZITADEL's audit logging captures enough detail to definitively identify exploitation attempts. If it doesn't, you may be flying partially blind on retrospective detection. Either way, patch first, audit second, and don't assume you're safe just because you haven't seen alerts.