ZITADEL EUVD-2026-113195

Exploitable only against a ZITADEL instance that serves the hosted Login V2 UI, and only for an active user who has not yet set ANY authentication method - no password, no passkey, and no linked identity provider - such as invited users or users created through the API before their first sign-in. The attacker must know that user's user ID or login name, and can then forge the verificationCheck cookie because its value is only a SHA-256 of the user ID and the browser fingerprint cookie, with no server-side secret involved. For the IdP-linking vector, an identity provider that allows account linking must be configured. Limiting factors confirmed by the vendor: users who already have any authentication method are not affected; deployments not serving Login V2 are not affected; and the ZITADEL APIs themselves are not affected. There is no configuration that fully closes the gap on unpatched versions - upgrading to 4.19.5 is the only complete fix; as a partial mitigation the vendor recommends creating users with an initial credential so no active user is left without an authentication method.

This is a genuine high priority, not a CVSS-inflated non-issue. The signals mostly align upward: the vendor (ZITADEL/GHSA-84fg-x5h4-w8xv) confirms a real authentication-bypass/account-takeover in the hosted Login V2 UI, VulnCheck independently published an advisory, and the vuln.today decision label is act_now. The CVSS 4.0 score is 9.1 (Critical) with network vector and no privileges or user interaction (AV:N/PR:N/UI:N) and high confidentiality and integrity impact (VC:H/VI:H), which matches an unauthenticated full account takeover. The tempering factors are built into the vector itself: AC:H and AT:P reflect real preconditions - the target must be an active user who has not yet set any authentication method, and the attacker must know that user's ID or login name. No availability impact (VA:N) and no scope/subsequent-system impact are claimed. Exploitation status: no public exploit identified at time of analysis - the two references are the vendor and VulnCheck advisories, not PoC or exploit code, and there is no CISA KEV listing. EPSS is not provided in the input, so probabilistic exploitation likelihood cannot be quoted. The mechanism is well documented and conceptually simple (the proof cookie was a SHA-256 of client-controllable values with no server-side secret), so the gap between 'no public exploit' and 'trivially reproducible' is small; the act_now label should be treated as authoritative despite the absence of KEV/EPSS.

An organization invites new users or provisions them via the ZITADEL API, leaving them active but without any password, passkey, or IdP link before first sign-in. An unauthenticated attacker who learns such a user's ID or login name computes a valid verificationCheck cookie (SHA-256 of the user ID and the browser fingerprint cookie - all client-known values), presents it to Login V2 as proof of recent verification, and sets a password (or registers a passkey, or links their own external IdP account), then signs in as that user and inherits its ZITADEL permissions and access to every downstream application. No public exploit code is identified at time of analysis, but the forging method is fully described in the vendor advisory.