GHSA 72q5 Mv5c Vxv4

ZITADEL’s hosted Login V1 UI allowed an unauthenticated attacker who knows only a victim’s login name to enroll attacker-controlled second factors on the victim’s account and to overwrite the victim’s verified phone number, before any password or other primary factor was verified. The multi-factor enrollment/initialization handlers acted on an identify-only login session—after the username was submitted, but before the first factor was checked.

An attacker who can reach a Login V1 authentication flow and knows a valid login name (no password required) can:

Enroll an attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F second factor on the victim’s account

Overwrite the victim’s verified phone number , including sending an SMS verification code to an attacker-chosen number

Enumerate users : the enrollment handlers returned discrepant errors for existing versus non-existing accounts, bypassing the Ignore unknown usernames protection

This affects applications that authenticate users through ZITADEL’s hosted Login V1 UI (OIDC/SAML).

This issue does not , on its own, result in account takeover: the attacker never learns the victim’s password, and Login V1 password reset is email-only. The impact is to the integrity of the victim’s account (an attacker-controlled second factor and/or phone number is planted) and the confidentiality of user existence (enumeration).

Scope note: This issue affects Login V1 only. It is instance-wide / cross-organization, but not cross-instance. Login V2 is not affected by this path. This is the second-factor counterpart to GHSA-45f2-5q3r-xgg6 , which closed the passwordless (passkey) enrollment gap but left these 2FA init/enrollment handlers ungated.

Systems running one of the following versions are affected:

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

3.x: 3.0.0 through 3.4.14 (including RC versions)

The vulnerability has been addressed in the latest releases. Login V1 now requires the auth request to have reached the MFA prompt step—which is only produced after the primary factor has been verified—before any second-factor enrollment, phone-number change, phone verification, or MFA initialization is performed. Because the enrollment command is never reached for an identify-only request, the user-enumeration discrepancy is closed as well.

4.x : Upgrade to $\ge$ 4.17.1

3.x : Upgrade to $\ge$ 3.4.15

The recommended solution is to upgrade to a patched version. There is no configuration that fully closes this gap on unpatched versions.

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

Thanks to Adam Korczynski (Ada Logics) and Lucas Dodgson (InfoGuard Labs) for reporting the vulnerability.