Summary
A vulnerability in ZITADEL Login V2 can expose OTP codes through server-action responses when the returnCode delivery type is used. An unauthenticated attacker who knows a victim's login name may obtain the victim's email and SMS OTP codes, establish an MFA-authenticated session, and potentially take over administrator accounts.
Affected context
The issue occurs in ZITADEL deployments using Login V2 where users have OTP-Email or OTP-SMS enrolled and the returnCode delivery type is available. Risk is higher when server-action responses expose authentication codes to an unauthenticated requester and when privileged accounts rely on these OTP methods for multi-factor authentication.
Exploit preconditions
- Attack surface: ZITADEL Login V2 authentication flow
- Required access: No authenticated access is required, but the attacker must know the target user's login name
- Trigger point: OTP enrollment or verification flows using the returnCode delivery type
- Why exploitation is possible: Server-action responses may disclose OTP codes before the user is authenticated, allowing the attacker to satisfy the OTP step and obtain an MFA-authenticated session
Why this happens
The vulnerability results from exposing authentication secrets in responses that are reachable before the requester has been authenticated. Returning OTP codes through a server-action response weakens the intended confidentiality of the second factor and permits an unauthenticated party with limited account information to complete authentication. This maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, with the exposed information being authentication credentials that can enable account access.
Potential impact
- An attacker may bypass the intended MFA protection
- User accounts could be taken over
- Administrator accounts could be compromised
- Attackers could gain access to protected application data and functions
- Compromised accounts could be used for persistence, impersonation, or further attacks
General mitigation guidance
Mitigation generally focuses on ensuring that OTP values remain confidential throughout authentication and are never returned to unauthenticated clients.
Common defensive patterns include:
- Avoiding response fields that disclose OTPs or other authentication secrets
- Binding OTP verification to the intended session, device, and transaction context
- Requiring authenticated or strongly bound channels for sensitive server actions
- Limiting OTP delivery options to secure, policy-approved mechanisms
- Applying least privilege to administrative accounts and separating high-risk administrative authentication from weaker factors
- Monitoring and rate-limiting login-name discovery, OTP requests, and verification attempts
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and API review rules that flag secrets included in pre-authentication responses
- Code review checks for OTP, recovery-code, and password-reset values returned by server actions
- Integration tests that verify unauthenticated responses contain no authentication credentials
- Policy enforcement requiring sensitive authentication data to remain server-side or use cryptographically bound delivery flows
- Monitoring for unusual OTP requests, repeated login-name targeting, and successful sessions preceded by anomalous authentication activity
Automated security review tools may help identify response schemas and code paths that expose sensitive values.
