GHSA 3gwm 5wx8 4gm6

ZITADEL’s hosted Login V2 UI allowed an unauthenticated attacker who knows only a victim’s login name to obtain a fully MFA-authenticated session for that victim — without any password, passkey, or IdP login — provided the victim already had both OTP-Email and OTP-SMS second factors enrolled. After the login name is submitted (an identify-only session, before any primary factor is verified), Login V2’s server action forwarded attacker-controlled challenge requests to the backend using the returnCode delivery type, which returns the generated OTP codes directly in the HTTP response instead of sending them to the victim’s mailbox or phone. Submitting both codes produced a session that ZITADEL treated as MFA-authenticated, because two second factors were counted as satisfying MFA.

An attacker who knows a valid login name — where the target already has OTP-Email and OTP-SMS enrolled and ready — can take over that account without knowing the password, using an existing authenticator, or interacting with the victim; both OTP codes are read directly from the server-action response. The resulting session token is accepted by ZITADEL’s APIs. If the victim is an instance administrator (e.g. IAM_OWNER ), this results in full instance takeover; for a non-privileged victim it is a takeover of that user’s account.

Scope note: This requires the victim to already have both OTP-Email and OTP-SMS enrolled and ready, on an instance whose login policy allows both factors and has an SMS provider configured. It affects applications that authenticate users through ZITADEL’s hosted Login V2 UI (OIDC/SAML). It is a separate issue from GHSA-45f2-5q3r-xgg6 : that advisory’s enrollment guard does not cover this path, because no new factor is enrolled — the attack reuses the victim’s existing OTP factors.

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.17.0 (including RC versions)

The vulnerability has been addressed in the latest release. The fix applies defense in depth: Login V2 no longer exposes the returnCode delivery type through its browser-facing server actions (OTP challenges are always sent out-of-band); the backend refuses a returnCode OTP challenge unless the session has already completed a primary authentication; and MFA is now evaluated as requiring a primary factor plus a second factor, so two second factors alone no longer satisfy MFA.

4.x : Upgrade to $\ge$ 4.17.1

The recommended solution is to upgrade to a patched version; there is no configuration that fully closes this gap on unpatched versions. To reduce exposure in the meantime, avoid having both OTP-Email and OTP-SMS enrolled on the same account — especially for privileged (e.g. IAM_OWNER ) users — and prefer TOTP, U2F/security keys, or passkeys as second factors. The attack is only possible against accounts that hold both OTP-Email and OTP-SMS.

If you have any questions or this advisory, please email us at [email protected]

Thanks to Lucas Dodgson from InfoGuard Labs ( @lucasdodgson ) for finding and reporting the vulnerability.