Act nowDisclosed

Advisory · CVE-2026-119128

Account takeover in ZITADEL Login V2 via a forgeable verification proof

ZITADEL 4.0.0 through 4.19.4 lets an unauthenticated attacker forge a verification proof cookie and set the first credential of a user who has none, taking over the account. ZITADEL rates it critical at CVSS 4.0 9.1.

Advisory published October 29, 2026Independent summary
Vendor
ZITADEL
Product
ZITADEL
Identifier / CWE
CVE-2026-119128
CWE-565
Action timing
Immediate
ELI5

Explain it like I’m five

After you verify your email, ZITADEL hands your browser a proof stamp so you can set your first password. But the stamp is just a hash of things the attacker already knows, so anyone can forge one and claim an account that has no password yet.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Target without credentials

    An attacker picks an active user who has no authentication method yet, such as an invited user or one created through the API.

  2. 02Proof forged

    The attacker computes a valid verificationCheck cookie from the user ID and browser fingerprint, with no server secret involved.

  3. 03First credential set

    Login V2 accepts the forged proof and lets the attacker set a password, register a passkey, or link an external identity provider.

  4. 04Account taken over

    The attacker signs in as the victim, with the victim permissions in ZITADEL and every application using it for sign-in.

What happened

ZITADEL disclosed CVE-2026-119128 in versions 4.0.0 through 4.19.4: Login V2 remembered a recent email or invite verification with a verificationCheck cookie that was only a SHA-256 hash of the user ID and the browser fingerprint cookie, values the client controls or can learn, with no server-side secret. Login V2 accepted that cookie as proof wherever a user without an authentication method sets up a first credential. ZITADEL rates it critical at CVSS 4.0 9.1.

Users who already have a password, passkey, or identity provider link are not affected, and the ZITADEL APIs themselves were not affected. The exposure is the onboarding window: invited and API-created users sitting without credentials.

What to do

  1. Inventory ZITADEL instances and list active users with no authentication method.
  2. Upgrade ZITADEL to version 4.19.5 or later, where verification proofs are signed with a server-side secret and expire after 5 minutes.
  3. As a partial mitigation before upgrading, create users with an initial credential so no active user is left without one.
  4. Ensure the session cookie secret is set to a randomly generated value of at least 32 characters.
  5. Review credential-setup events for accounts whose first credential was set unexpectedly, and reset those accounts.

Management note

A forgeable proof in an identity provider turns onboarding into account takeover. Close the no-credential window first, then patch.