How I Found an OTP Authentication Bypass While Hunting for Bugs

Bug hunting is often unpredictable. Sometimes you spend hours testing complex functionality and find nothing. Other times, a seemingly simple feature ends up exposing a significant security issue.

This is the story of how I discovered an OTP Authentication Bypass vulnerability in an order tracking system, a finding that was ultimately triaged as P3 (Medium Severity).

The Hunt Begins

I was exploring an e-commerce platform as part of my routine bug hunting process. Instead of focusing immediately on high-profile areas such as payments or account management, I decided to inspect some of the less obvious functionality.

One feature that caught my attention was the Order Tracking page.

The workflow appeared straightforward:

Enter an order number.
Enter the associated email address.
Receive an OTP via email.
Verify the OTP.
Access order tracking details.

Since OTP implementations are frequently affected by logic flaws, I decided to investigate the verification process more closely.

Initial Testing

To understand how the feature worked, I entered a valid order number and email address.

The application prompted me for an OTP that had been sent to the registered email address.

Instead of entering the correct OTP, I intentionally submitted:

As expected, the application rejected the request.

The server responded with:

{
  "success": false,
  "message": "Invalid OTP. Attempts remaining."
}

{
  "success": false,
  "message": "Invalid OTP. Attempts remaining."
}

The response was accompanied by an HTTP 400 status code.

At first glance, everything seemed to be functioning correctly.

However, I wanted to understand exactly how the frontend handled the OTP verification response.

Looking Closer

Using an intercepting proxy, I captured the OTP verification request and its corresponding response.

While reviewing the response, I noticed that the application appeared to rely heavily on a JSON parameter named:

"success"

"success"

This immediately raised a question:

What would happen if the client received a successful response even though the OTP was invalid?

To test this theory, I intercepted the server response before it reached the browser.

The Experiment

I modified the response:

Original Response

{
  "success": false,
  "message": "Invalid OTP. Attempts remaining."
}

{
  "success": false,
  "message": "Invalid OTP. Attempts remaining."
}

Modified Response

{
  "success": true,
  "message": "Valid OTP"
}

{
  "success": true,
  "message": "Valid OTP"
}

I also changed the HTTP status code from:

400 Bad Request

400 Bad Request

to:

200 OK

200 OK

After forwarding the modified response to the browser, something unexpected happened.

The application proceeded as if the OTP verification had succeeded.

Authentication Bypassed

Despite never possessing the correct OTP, I was granted access to the order tracking functionality.

At this point, it became clear that the application was trusting data received by the client rather than enforcing authentication state exclusively on the server.

The security control designed to protect access to order information could be bypassed through simple response tampering.

No OTP cracking.

No brute force.

No race conditions.

Just a modified response.

Root Cause

The underlying issue appeared to be a classic Client-Side Trust Vulnerability.

Rather than validating authentication status server-side and enforcing access controls on protected resources, the application relied on client-visible values indicating whether OTP verification had succeeded.

Since anything sent to a client can be modified by an attacker, this approach creates an opportunity for authentication bypass.

A secure implementation should:

Perform OTP validation entirely on the server.
Store verification state server-side.
Validate authentication before serving protected resources.
Never trust client-side success indicators.

Potential Impact

An attacker with knowledge of a valid order number and associated email address could potentially:

Bypass OTP verification.
Access order tracking information.
View shipment status and order details.
Access information intended only for legitimate customers.

The exact impact would depend on the data exposed through the tracking portal.

Disclosure and Outcome

After validating the issue and documenting the attack path, I responsibly reported the vulnerability through the platform's bug bounty program.

Following review by the security team, the report was accepted and triaged as:

Priority: P3 (Medium Severity)

Final Thoughts

This finding serves as a reminder that security vulnerabilities are not always hidden behind complex attack chains. Sometimes, a simple workflow combined with a misplaced trust assumption can create a meaningful security issue.

When testing applications, it is often worth spending time on seemingly ordinary features. Authentication flows, password resets, OTP implementations, and tracking portals frequently contain logic flaws that are easy to overlook during development.

In this case, a routine examination of an order tracking feature led to the discovery of an OTP Authentication Bypass caused by client-side trust — a vulnerability that could have allowed unauthorized access to customer order information.

Happy Hunting!

Contents