Description

ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 contains a missing authentication flaw in the hosted Login V1 UI, whose second-factor enrollment and initialization handlers act on an identify-only session before any primary factor is verified. Attackers knowing only a victim's login name can enroll attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F factors, overwrite the verified phone number, and enumerate users through discrepant errors.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-10-04T15:16:32.170Z",
  "pubdate": "2026-10-04T15:16:32.170Z",
  "executiveSummary": "ZITADEL versions 3.x before 3.4.15 and 4.x before 4.17.1 are susceptible to an authentication bypass vulnerability within the hosted Login V1 UI. The flaw stems from a failure to validate primary authentication factors before processing second-factor enrollment and initialization requests.\nThis vulnerability allows an unauthenticated remote attacker who possesses only a victim's login name to perform unauthorized modifications to security settings. By interacting with the vulnerable second-factor handlers, an attacker can register arbitrary TOTP, OTP-SMS, OTP-Email, or U2F authentication factors, effectively hijacking control of the account's multi-factor authentication (MFA) configuration.\nAdditionally, the flaw allows for the overwriting of verified contact information (phone numbers) and facilitates user enumeration via discrepant error messaging. This represents a critical security risk, as it permits full account takeover without requiring knowledge of the victim's primary credentials. Exploitation requires no prior authentication, as the affected handlers process identity-only sessions prematurely. Organizations running the affected versions are at significant risk of unauthorized access and identity theft, necessitating immediate patching.",
  "technicalDetails": "The vulnerability resides in the ZITADEL Login V1 UI component, specifically within the second-factor enrollment and initialization handlers. The root cause is a missing authentication check that fails to verify the status of the primary factor before permitting state-changing operations on a session object.\nIn a secure implementation, handlers responsible for MFA initialization and contact verification must validate that the session has successfully completed the primary authentication phase (e.g., password or passkey validation). In the affected ZITADEL versions, the system incorrectly trusts an 'identify-only' session state. This state is generated immediately upon submission of a login name, before the identity is confirmed or a password is verified.\nThe attack flow proceeds as follows: 1. The attacker initiates an authentication flow using the victim's login name. 2. Upon reaching the identification stage, the application session enters an identify-only status. 3. The attacker bypasses the required primary credential verification by sending crafted requests directly to the second-factor enrollment handlers. 4. The vulnerable handlers process these requests, erroneously accepting them as valid because the session identifier is associated with the victim's account, even though authentication is incomplete. 5. Through these requests, the attacker can enroll their own TOTP, OTP-SMS, OTP-Email, or U2F device. 6. Simultaneously, the attacker can overwrite verified recovery information such as phone numbers to ensure persistence or bypass password reset mechanisms.\nThe inability of the system to enforce strict state transitions allows the attacker to move directly from the identification phase to the account modification phase. Furthermore, the application provides discrepant error messages during these interactions, which allows an attacker to enumerate valid user accounts by observing variations in system responses. The impact of this exploit is severe, as it facilitates full account compromise, enabling the attacker to intercept MFA challenges or permanently redirect authentication flow control. There are no privilege requirements, and the vulnerability is accessible via the standard network-exposed authentication interface. The affected versions (3.x prior to 3.4.15 and 4.x prior to 4.17.1) demonstrate a systemic failure in the authentication state machine, allowing unauthenticated attackers to manipulate user security credentials."
}