Universal OTP to 0-Click Account Takeover: How a Static Verification Code Bypassed Authentication

• Attack Surface
• Offensive Security
• Red Teaming

During a recent penetration testing engagement, Velstadt’s Offensive Security team discovered a critical vulnerability in the authentication process of a web application. The issue allowed an attacker to log in to any registered customer account by using a universal one-time password.

Because the attacker only needed to know the victim’s email address and did not require any action from the victim, the issue can be described as a 0-click account takeover vulnerability.

The application used email-based OTP authentication. Normally, a user should receive a unique verification code by email and use this code to complete the login process. However, during testing we found that the backend accepted the static OTP value 1250 for any registered user.

The result was a direct authentication bypass: knowing a registered email address was sufficient to obtain valid authentication tokens and access the corresponding account.

The engagement has been anonymized. Technical details are preserved where appropriate for educational purposes.

TL;DR — Key Takeaways

• Vulnerability: Universal static OTP accepted by the production authentication backend.
• Attack requirement: Knowledge of a registered user’s email address.
• Victim interaction: None. The attacker did not require access to the victim’s mailbox, password, active session, or legitimate OTP.
• Result: Successful authentication and issuance of valid access and refresh tokens.
• Impact: Full account takeover with the permissions assigned to the compromised user.
• Primary security classification: OWASP Top 10:2025 — A07: Authentication Failures; CWE-287: Improper Authentication.
• Contributing weakness: A hardcoded or otherwise static authentication value in production may also be relevant to CWE-798: Use of Hard-coded Credentials, depending on the underlying implementation.
• Risk Level: Critical — the vulnerability allowed unauthenticated takeover of any registered customer account using a universal static OTP.
• Possible root cause: Development or testing logic, environment configuration, or another implementation issue may have caused the static verification value to remain available in the production authentication flow.

How the Vulnerability Works

The vulnerable authentication flow used the following endpoint:

POST /api/v1.0/one-time-login-via-email/customer

To reproduce the issue, an attacker only needed to know the email address connected to the victim’s account. The attacker could then send a request with the victim’s email address and use 1250 as the verification code.

For example:

{
"email": "[email protected]",
 "verificationCode": "1250"
}

The server accepted the code and returned valid authentication data, including an access token and a refresh token.

This means that the attacker did not need access to the victim’s mailbox, password, current session, or real OTP code. The victim also did not need to click a link, approve a request, or interact with the attacker in any way.

As a result, the vulnerability allowed a practical 0-click account takeover, where knowledge of the registered email address was enough to compromise the account.

Registered email addresses may often be obtained through account enumeration, previous data exposures, or public sources, further lowering the practical barrier to exploitation.

Why This Is an Authentication Bypass

The security of an email OTP flow depends on the backend verifying that the submitted code is valid, unexpired, and bound to the intended user and authentication attempt.

In this case, that security property was effectively removed.

Instead of requiring possession of the OTP delivered to the legitimate user’s mailbox, the backend accepted a known static value. Once that value was discovered, the email verification step no longer demonstrated control of the registered email account.

After the authentication check succeeded, the backend issued valid access and refresh tokens to the attacker.

This is why other security controls could not compensate for the authentication flaw. HTTPS could protect the authentication request in transit, but it could not prevent the backend from accepting an invalid verification code and issuing valid tokens.

Security Impact

The vulnerability resulted in a full account takeover.

Using the universal OTP 1250, an attacker could access any account registered on the affected platform and operate with the same permissions as the victim.

Since no user interaction was required, the attack could potentially be performed against multiple known accounts without phishing, malicious links, or social engineering. Because the backend issued valid authentication tokens, subsequent activity could appear legitimate to security controls, making malicious activity harder to distinguish from normal account usage without additional behavioral or contextual detection.

The exact impact depends on the functionality available within the account. In many applications, this may include access to personal data, account settings, private information, business data, or other authenticated features.

If privileged or administrative accounts use the same authentication mechanism, the impact may be even more serious.

Possible Root Cause

Universal OTP codes are sometimes introduced during development or testing. Developers may use a static verification code to simplify automated testing or avoid relying on email delivery during development.

The problem arises when this logic remains available in the production environment.

If this test logic is not removed or properly restricted before deployment, it can create a direct authentication bypass.

This type of issue can also result from incorrect environment configuration, forgotten debug functionality, hardcoded test values, or shared authentication logic between testing and production systems.

Even if the application uses HTTPS, secure tokens, strong passwords, and other security controls, those protections cannot compensate for an authentication backend that accepts a universal verification code.

Security Classification

Framework	Classification	Relevance
OWASP Top 10:2025	A07 — Authentication Failures	The application accepted a universal OTP that did not prove control of the registered email account, resulting in improper authentication.
CWE	CWE-287 — Improper Authentication	The application failed to sufficiently verify that the party completing authentication was the legitimate account holder.
CWE — Conditional	CWE-798 — Use of Hard-coded Credentials	May apply if code or configuration review confirms that the universal OTP was implemented as a hardcoded authentication value.

CWE-287 is the primary weakness classification based on the behavior confirmed during testing. CWE-798 may also apply if code or configuration review confirms that the universal OTP was implemented as a hardcoded authentication value.

Risk-Based Remediation Priorities

The exact remediation timeline depends on the application architecture, business criticality, change-management process, and operational constraints. For an authentication bypass capable of issuing valid access and refresh tokens for arbitrary registered accounts, remediation should prioritize removal of the bypass, validation of the surrounding authentication logic, and assessment of potentially affected sessions.

Priority 1 — Eliminate the Authentication Bypass

• Remove the universal OTP from production: Ensure that the static verification value is no longer accepted by any production authentication endpoint.
• Verify OTP binding: Ensure that every accepted OTP is validated against the intended user and authentication attempt.
• Review for equivalent bypasses: Check authentication code and configuration for additional static OTPs, fallback codes, debug credentials, support mechanisms, bypass flags, or other authentication shortcuts.

Priority 2 — Review Existing Authentication State

Because the vulnerable flow issued valid access and refresh tokens, assess whether sessions or tokens may have been created through the bypass before remediation.

Depending on the application’s token architecture, available logging, and incident assessment, appropriate actions may include:

• revoking potentially affected refresh tokens;
• invalidating active sessions where necessary;
• requiring re-authentication for affected users;
• reviewing authentication logs for suspicious use of the vulnerable flow.

The scope of token or session invalidation should be based on the available evidence, exposure window, and operational impact.

Priority 3 — Harden OTP Verification

OTP implementations should include:

• cryptographically secure random generation;
• server-side association with the intended user and authentication attempt;
• short, defined expiration periods;
• single-use enforcement;
• limits on failed verification attempts;
• controls against automated guessing;
• secure logging and monitoring of authentication failures and anomalous successes.

These controls should be designed carefully to reduce brute-force risk without introducing an easily exploitable denial-of-service condition against legitimate users.

Priority 4 — Prevent Test Logic from Reaching Production

• Development, QA, staging, and production environments should use clearly separated authentication configurations.
• Static OTPs or similar authentication shortcuts used for automated testing should be restricted to isolated non-production environments.
• Where feasible, CI/CD controls should prevent known test-only authentication mechanisms from being deployed or enabled in production.

Priority 5 — Validate the Fix

After remediation, perform targeted retesting to confirm that:

• the universal OTP is no longer accepted;
• OTPs are correctly bound to the intended user and authentication attempt;
• expired or reused OTPs are rejected;
• anti-automation controls behave as intended;
• no equivalent bypasses remain accessible through alternate login, recovery, or support flows.

The broader authentication implementation should also be reviewed for similar logic flaws that may not have been exercised during the original test.

Detection and Monitoring Considerations

Because exploitation results in valid authenticated sessions, security teams should review available authentication and application telemetry for signs that the vulnerable flow may have been abused.

Relevant indicators may include successful authentication without the expected preceding OTP-generation event, repeated authentication across multiple accounts from the same source, anomalous device or geographic patterns, and suspicious activity involving privileged accounts or refresh tokens.

Detection logic should be adapted to the application’s authentication architecture and available telemetry rather than relying on any single indicator.

About Velstadt Offensive Security

Velstadt’s Offensive Security practice combines manual testing with targeted automation to identify vulnerabilities in web applications, APIs, authentication and authorization mechanisms, session management, and business logic.

Our penetration testers assess not only individual weaknesses but also how they can be combined into realistic attack paths within the agreed scope and rules of engagement.

Frequently Asked Questions (FAQ)

How should a universal OTP vulnerability be retested after remediation?

Retesting should verify that the universal value is no longer accepted, OTPs are correctly bound to the intended user and authentication attempt, expired or previously used codes are rejected, and alternate login, recovery, or support flows do not expose equivalent bypasses.

Can security monitoring detect abuse if the attacker receives valid authentication tokens?

Potentially, but detection may be more difficult because subsequent activity can resemble legitimate authenticated usage. Behavioral and contextual signals, such as successful authentication without the expected preceding events in the authentication flow, unusual device or geographic patterns, anomalous session activity, or authentication across multiple accounts from the same source, may help identify potential abuse.

When would CWE-798 apply to a universal OTP vulnerability?

CWE-798 may apply if code or configuration review confirms that the universal OTP was implemented as a hardcoded authentication value. Without that implementation-level evidence, CWE-287 (Improper Authentication) is the more appropriate primary classification.

References and Sources

1. OWASP Top 10 (2025): A07 Authentication Failures
2. OWASP: Web Security Testing Guide
3. OWASP: Authentication Cheat Sheet
4. PortSwigger Academy: Authentication Vulnerabilities
5. PortSwigger Academy: Multi-Factor Authentication Vulnerabilities
6. CWE: CWE-287 Improper Authentication
7. CWE: CWE-798 Use of Hard-coded Credentials