Hi, let me introduce myself — I'm Kanishka Khandelwal, currently working as an Associate Security Engineer, and apart from my day job, I spend most of my time doing bug bounty.

While testing authentication systems, most people focus on OTP bypass or brute force.

But sometimes… the issue isn't breaking OTP.

It's how OTP is delivered.

And this finding is exactly about that.

🎯 Initial Testing

I was testing a target (let's call it target.com).

As usual, I started with:

  • Registration flow
  • OTP verification
  • Login functionality
  • Intercepting requests via Burp Suite

One important thing I noticed early:

👉 The application did not have a password-based login system 👉 Authentication was completely OTP-based (email/phone)

This detail later became very important for the impact.

🔍 Testing OTP & Email Binding

While testing OTP verification, I checked how the application binds OTP with the entered email.

At this point, I tried modifying the email input like this:

"email": "victim@mail.com,cc:attacker@mail.com"

The application accepted it.

Now here's what I observed:

👉 During registration, the system treated the full string as a single email:

victim@mail.com,cc:attacker@mail.com

👉 During OTP delivery:

  • OTP was sent to victim email
  • OTP was also sent to attacker email (via cc)

⚠️ Interesting Behavior

Even though I received the OTP on my attacker email, there was an important limitation:

👉 During login, when I entered only the victim's email:

victim@mail.com

👉 The application responded: "Email not registered"

This clearly showed:

  • The system stored the entire injected string as one identity
  • victim@mail.com ≠ victim@mail.com,cc:attacker@mail.com

So effectively:

  • Account identity = full injected string

🧠 Why This Reduced Initial Impact

At this stage:

✅ OTP leakage confirmed ❌ No direct takeover

Because:

  • It behaved like a new account
  • Not linked to the real victim

I also tested variations:

victim@mail.com,attacker@mail.com   // TO
victim@mail.com,cc:attacker@mail.com // CC
victim@mail.com,bcc:attacker@mail.com // BCC

👉 All resulted in OTP leakage.

🤔 No Impact Yet… So I Went Deeper

At this stage, I had:

✅ OTP leakage ❌ No meaningful impact

So I continued testing further functionalities.

🚪 Email Change Functionality

After logging in with my attacker-controlled account, I found an option to change email.

I tried:

victim@mail.com,bcc:attacker@mail.com

⚡ Validation Bypass

The application responded:

👉 "Email already in use"

But…This indicates that the parameter is being evaluated using only the victim's email, rather than treating the entire input as a single string.

In other words:

  • During registration → full input is treated as one identity
  • During validation → only the primary email (victim@mail.com) is extracted and checked

👉 This inconsistency in how the same parameter is handled across different flows is what makes the bypass possible. Then I intercepted the request and modified the response:

  • 400 → 200 OK
  • status 0 → 1

👉 The system accepted it.

💥 OTP Leakage + Identity Binding

Now OTP was sent to:

  • victim email
  • attacker email

I used the OTP from my attacker inbox.

And…

💥 Email was successfully updated to victim's email

🚨 Final Impact — Account Collision

Now the system state became:

👉 Attacker account linked to victim email

When the victim logged in:

  • OTP verification succeeded
  • But they were redirected to the attacker-controlled account

👉 This resulted in both attacker and victim sharing the same account session/state, allowing access to the same data and functionality

⏳ Important Limitation (OTP-Only System)

Since the application was OTP-only (no password login):

👉 The shared access/session collision remained valid only until the OTP session expired

After expiry:

  • Re-authentication was required
  • Control could shift depending on who logs in first

Even though this limits persistence…

👉 The impact is still critical because:

  • Unauthorized access is achieved
  • Sensitive data can be viewed/modified
  • Trust in authentication is broken

🧠 Important Observation

This vulnerability chain required:

  • Email injection (cc, bcc, ,)
  • OTP leakage
  • Weak email-to-account binding
  • Email change logic flaw
  • Response manipulation

Individually → low/medium 👉 Combined → Critical

❓ Pre-Account Takeover Possibility?

Yes — partially.

For unregistered emails:

  • OTP can be intercepted
  • Account can be created by attacker

For registered users:

👉 Requires:

  • Email change abuse
  • Identity binding flaw

💥 Impact

  • OTP leakage
  • Unauthorized account access
  • Email hijacking
  • Account collision
  • Shared session & data exposure

👉 Complete authentication logic breakdown

Disclosure Experience

The vulnerability was responsibly disclosed as per the platform's bug bounty / disclosure program. However, there was no response or acknowledgment from the team after submission.

Honestly, this can be a bit frustrating, but it's also part of the reality of bug bounty programs where responses and rewards are not always guaranteed.

THANK YOU

If you found this helpful, feel free to connect: LinkedIn: https://www.linkedin.com/in/kanishka-khandelwal-a49050263/

Or drop your thoughts in the comments…