ZITADEL Account-Takeover Flaws CVE-2026-105207, -105209 and -105215: Fixed Versions and What to Check

If you run ZITADEL, the open-source identity platform, check the version number today. Three critical flaws, each of which lets an attacker take over someone else’s account, were fixed in releases between mid-July and early September 2026, but their CVE records were published on October 4, 2026. Anything older than 4.17.3 is affected by at least one of them, and ZITADEL 3.x has no fix for the most serious one.

This article lays out which versions are affected by each flaw, what each requires from an attacker, and which questions to ask of your own logs. It is based on ZITADEL’s GitHub security advisories and the CVE records; we did not install ZITADEL or test any of the flaws.

The three flaws

All three are authorization or verification failures around how an account gets tied to a login method. The details come from ZITADEL’s advisories, and the dates and CVSS 4.0 scores from the CVE records, which were published by VulnCheck, acting as CVE Numbering Authority (the organization authorized to issue the CVE IDs).

An IdP (identity provider) is an external service such as a company directory or social login that vouches for a user’s identity. A passkey is a phishing-resistant sign-in credential bound to a device, covered in our comparison of passkeys and passwords.

What each one means in practice

CVE-2026-105207 is the broadest. ZITADEL’s advisory says an attacker who knows only a victim’s login name can bind their own external identity to the victim’s account through the Login V2 identify-only session, then sign in as the victim. The same weakness is reachable through the API endpoint that adds IdP links, so changing the login screen does not close it. The advisory says it needs no authentication, no privileges and no user interaction. If your instance allows external IdP sign-in at all, treat this as the priority.

CVE-2026-105209 matters most for multi-tenant setups. If you use separate ZITADEL organizations for separate customers or business units on one instance, an administrator in one organization could obtain an enrollment code for a user in another and register their own authenticator. The attacker needs a legitimate foothold first, so for a single-organization company the realistic threat is an insider or a compromised administrator account. For a service that gives each customer an organization, a customer administrator is a possible attacker.

CVE-2026-105215 is a pre-hijack. The attacker creates an account in advance, bound to the victim’s external identity. The victim’s first genuine sign-in through that IdP then lands in the attacker-prepared account. It needs the victim’s external user ID, which the advisory says may be known or predictable, and only Login V1 is affected.

When the fixes actually shipped

The CVE records were published on October 4, 2026; two of them (CVE-2026-105209 and CVE-2026-105215) were updated on October 5. The fixes are older. The “public” dates in the CVE records are July 29, August 14 and September 4, 2026 for CVE-2026-105215, CVE-2026-105209 and CVE-2026-105207, respectively. ZITADEL’s releases page lists 3.4.15 and 4.17.1 as released August 14, 2026 and 4.17.3 as released September 4, 2026, which matches. It lists 4.16.2 and 3.4.14 as released July 29, 2026, which also matches.

Two consequences follow. First, an organization that kept to a routine upgrade cadence may already be on a fixed build without having seen any alert. Second, an organization that skipped those releases has been exposed for weeks to flaws whose fixes were public, and the CVE publication on October 4 makes the technical detail easier for others to find. Whether anyone used them in that window is something we found no reporting on.

Where the sources disagree or are unclear

• Version ranges for CVE-2026-105207. ZITADEL’s advisory lists 3.0.0 through 3.4.15 and 4.0.0 through 4.17.2 as affected, with 4.17.3 as the fix. The CVE record’s text agrees, but its structured data also contains a second block that lists versions up to and including 4.19.4 as affected. That contradicts the advisory, which names 4.17.3 as the fixed release, and would flag a patched 4.19.4 server in any scanner that reads that field. We treat the advisory as authoritative and note the record’s data as inconsistent; we have not seen a correction.
• Severity numbers. A widely circulated summary lists the three flaws as 9.8, 9.6 and 9.1. Those are the CVSS 3.1 scores. On CVSS 4.0, which the CVE records also carry, all three score 9.3. The two are different scales and should not be compared against each other.
• What “latest” is. The newest release we found on October 6 was 4.19.4, dated October 1, 2026. The release notes for 4.19.2 (September 28, 2026) say it addresses three further vulnerabilities: two rated High, both account takeover issues (advisories GHSA-x4c7-fpcx-w9q6 and GHSA-jh92-5mrj-p2w2), and one rated Low (GHSA-w4gv-rcwj-w6r5). We did not review those advisories in detail, and they are separate from the three CVEs covered here.

What to do, in order

This sequence is our recommendation, built on ZITADEL’s advisories.

1. Find every instance and its version

Include development, staging and any instance that serves a single customer. Record whether it runs 3.x or 4.x, and whether Login V1, Login V2 or both are enabled, since that decides which flaws apply.

2. Upgrade to 4.17.3 or later, preferably the newest 4.x

Fixing all three requires at least 4.17.3. Given the further fixes in 4.19.2, aim for the newest 4.x release. One upgrade requirement to plan for: the 4.19.2 release notes say Login V2 now requires session cookie signing, that the ZITADEL_SESSION_COOKIE_SECRET environment variable (at least 32 characters) must be set before upgrading, and that users have to sign in again afterward. If you are on 3.x, plan the move to 4.x now: the advisory for CVE-2026-105207 says the 3.x line reached end-of-life on August 31, 2026 and will not be patched, so staying on 3.x leaves that flaw open. Test the upgrade first, because a major-version move can change login behavior.

3. If you must wait, apply the partial workarounds and limit exposure

ZITADEL lists two partial workarounds. Disabling external IdP account linking reduces the CVE-2026-105207 route through Login V2 but not the API route. Disabling manual account creation on external IdPs reduces CVE-2026-105215 but turns off legitimate self-service registration. For CVE-2026-105209 the advisory says no configuration workaround fully addresses it. Our own suggestion, not ZITADEL’s: where an instance is only used by staff, restricting it to a VPN or an allowlist of source addresses reduces the number of people who can reach the vulnerable endpoints, though it does not help against CVE-2026-105209, where the attacker is already an authenticated administrator.

4. Look for takeovers that already happened

Upgrading removes the flaw, not an attacker who has already taken an account. We did not verify ZITADEL’s log or event names, so use your own audit logs and match these questions to what they record:

• IdP links. Have any existing accounts gained an external IdP link that the owner did not create, especially since August 2026? A takeover through CVE-2026-105207 leaves a new link on the victim’s account.
• Passkey and passwordless enrollment. Were enrollment codes issued by an administrator in organization A for a user in organization B? Did any account register a new authenticator it did not request?
• Accounts created through external sign-in that no real person used. Pre-hijack accounts are created through the registration endpoint, with an external identity attached before the real person arrives.
• Sign-ins that follow one of those changes from an unfamiliar address or device.

If you find a suspicious link or authenticator, remove it, revoke the account’s active sessions and review what the account could reach. Our guide to detecting leaked keys and rotating them covers the follow-up for any secrets those accounts could read.

5. Keep the logs

Make sure identity-provider events are retained somewhere an attacker with administrator rights in one tenant cannot erase them. The reasoning is in our piece on logging for incidents rather than dashboards.

What this says about identity systems generally

The three flaws share one pattern, which is our reading, not ZITADEL’s: the system trusted a claim about who was acting without checking it where the change happened. In CVE-2026-105207 it was a link request, in CVE-2026-105209 a header naming an organization, and in CVE-2026-105215 identity fields supplied by the browser. When you review any identity platform, including a hosted one, ask where an account’s credentials can be added or changed, and what is checked at that exact step.

The timing is also a lesson. These are fixed-before-disclosed flaws, and the organizations hurt are those that treat identity software as set-and-forget. Put your identity provider on the same patch watchlist as your edge devices, and rank it using the approach in our vulnerability backlog piece.

Sources and verification

Checked on October 6, 2026. We did not install ZITADEL, test any flaw or review its source code. ZITADEL’s advisories and releases page were read through a page-summarizing tool; the CVE records were read directly from the CVE Program API. The affected-version lists, workarounds and release dates below should be checked against the primary pages before you act on them.

IAMAuthenticationVulnerability Management