Description

ZITADEL 3.x before 3.4.14 and 4.x before 4.16.2 contains an authentication bypass in the hosted Login V1 and Login V2 UIs that accepts passkey or other authenticator enrollment on identify-only login sessions, before any primary factor is verified. Unauthenticated attackers knowing only a victim's login name can register an attacker-controlled authenticator and log in as that user, bypassing existing passwords and MFA.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-04T15:16:32.520Z",
  "pubdate": "2026-10-04T15:16:32.520Z",
  "executiveSummary": "A critical authentication bypass vulnerability exists within ZITADEL 3.x (before 3.4.14) and 4.x (before 4.16.2), specifically affecting the Login V1 and Login V2 UIs.\nThe flaw stems from an improper state validation during the authentication lifecycle, allowing the enrollment of new passkeys or authenticators on sessions that have not yet undergone primary factor verification.\nThis vulnerability grants unauthenticated attackers the ability to compromise victim accounts by merely possessing the target's login identifier.\nBy registering an attacker-controlled authenticator, an adversary can bypass all existing authentication mechanisms, including passwords and pre-configured Multi-Factor Authentication (MFA).\nThe impact is a complete account takeover, leading to unauthorized access to sensitive user data, identity impersonation, and potential escalation of privileges within the ZITADEL environment.\nSuccessful exploitation requires minimal interaction beyond the knowledge of a valid username and the ability to interact with the publicly exposed login interface, posing a severe risk to organizational security and user privacy.",
  "technicalDetails": "The vulnerability is rooted in a failure of the session state management mechanism within the ZITADEL Login V1 and Login V2 components. Specifically, the application fails to enforce a strict verification prerequisite before allowing the registration of new authentication factors during the login flow.\nUnder normal operating conditions, a user should only be permitted to enroll new passkeys or MFA devices after successfully authenticating with primary credentials. However, in the affected versions, the implementation accepts enrollment requests during the identify-only phase of the login process, before the primary factor has been validated.\nThe attack flow begins when an attacker identifies a valid user's login name. The attacker initiates a login request through the vulnerable UI. Because the session state does not mandate a verified status, the attacker can proceed to the authenticator enrollment endpoint.\nBy submitting a registration request for an attacker-controlled authenticator, the ZITADEL backend binds this new, malicious credential to the victim's account identity. Once the registration is successful, the attacker can leverage this newly enrolled device to perform a full authentication bypass.\nThis circumvents existing passwords and any previously configured MFA, as the system treats the attacker's newly registered authenticator as a valid, authorized factor for the user identity. This effectively grants the attacker persistence and complete control over the compromised account.\nThe vulnerable component is identified within the session management logic of the login UI handlers. The flaw is present in both 3.x and 4.x branches of ZITADEL. Because this login functionality is typically exposed to the public internet, the attack surface is significant, requiring no special network access or prior privilege levels beyond the ability to reach the authentication portal.\nThe post-exploitation impact allows for seamless account takeover and potential lateral movement if the compromised account possesses administrative privileges within the ZITADEL identity provider configuration."
}