ZITADEL published a critical advisory on 4 October 2026 for an account-linking flaw tracked as CVE-2026-105207. On hosted Login V2, an identify-only session is created by submitting a login name. No password or MFA is checked. From that session an unauthenticated attacker who knows the login name can bind their own external identity provider to the victim account, then sign in as the victim.
What happened
The product created external identity links without checking that a primary factor had been verified or that the caller was allowed to create the link. The same gap is reachable on the User Service V2 AddIDPLink endpoint. Any authenticated user can pre-claim an external identity on their own account. Because those links are globally unique, first claim wins, which can block a later legitimate federated login.
GitHub rates the issue 9.8. Login V1 is not affected: it only links after primary-factor and MFA checks. The flaw is instance-wide, including across organizations on the same instance, but not across separate ZITADEL instances. Organizations that allow manual external IdP account linking are the practical target.
Who is affected
- ZITADEL 4.0.0 through 4.17.2, including release candidates
- ZITADEL 3.0.0 through 3.4.15, including release candidates
- Apps that authenticate through hosted Login V2 (OIDC or SAML), plus any deployment exposing User Service V2
The 3.x line reached end of life on 31 August 2026 and will not get a fix for this issue.
What to do now
Upgrade 4.x to 4.17.3 or later. Move any remaining 3.x deployment onto a patched 4.x release. There is no setting that fully closes the gap on an unpatched build. Disabling external IdP account linking in the login policy only closes the Login V2 path. It does not close the API path. After the upgrade, review existing external identity links for unexpected bindings.
Source: ZITADEL security advisory GHSA-g8gj-gq47-xgf4.
Also on the blog
- CVE-2026-88779 crashes SAML NetScaler, patch by 7 October
- GitLab AI Gateway sandbox escape is a 9.9, patches are out
- TA419 phishes AI policy experts with Microsoft AitM
- ShinyHunters suspect Rey detained in Jordan, sources say
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.