One Parameter One User’s Phone Number And Someone Else’s Email Address Famous Bus Booking in India

Last night, while casually poking around a Intrcity application (definitely not trying to swipe right on vulnerabilities), curiosity kicked in. A few harmless parameter tweaks later… and suddenly, I wasn't just reading my own messages anymore.

Turns out, the app trusted API Calls is more than it should.

Nothing fancy.

No SQL injection.

No complicated exploit chain.

No brute force.

Just a parameter that looked a little too trusting.

A few harmless changes later, I realized the application was allowing me to request information associated with a different user's phone number.

And that information included something that should never have been exposed to an unauthorized user:

Their email address.

Unauthorized User Email Disclosure

The issue can be categorized primarily as:

CWE-639 —> Authorization Bypass Through User-Controlled Key

and also:

CWE-200 —> Exposure of Sensitive Information to an Unauthorized Actor

The core problem was simple:

The server appeared to trust a client-controlled identifier when determining which user's information should be returned.

The application should have established:

"Who is making this request?"

and then verified:

"Is this user actually authorized to access this account?"

Instead, the logic appeared closer to:

"Which phone number did the client send?"

That difference is where the vulnerability lived.The Finding

The vulnerable functionality involved an API endpoint used during the application's user-related workflow.

The endpoint accepted a parameter named:

verified_number

At first glance, nothing seemed unusual.

The application appeared to use the supplied phone number to identify the corresponding user.

But then came the interesting part.

What happens if the phone number supplied by the client belongs to someone else?

I tested that scenario in a controlled manner.

And the server responded with information associated with the other account.

That shouldn't happen.

Proof of Concept

For obvious privacy reasons, I'm redacting actual phone numbers and email addresses.

Request

GET /sample/p/******User.json?verified_number=<USER_B_PHONE>
Host: <REDACTED>

GET /sample/p/******User.json?verified_number=<USER_B_PHONE>
Host: <REDACTED>

The request was sent while authenticated as User A.

However, the supplied phone number belonged to User B.

Expected Behavior

The server should have rejected the request because User A should not be able to retrieve User B's account information.

Something along the lines of:

{
  "status": false,
  "message": "Unauthorized"
}

{
  "status": false,
  "message": "Unauthorized"
}

or an equivalent authorization failure.

Observed Behavior

Instead, the API processed the supplied identifier and returned information associated with User B.

For example, conceptually:

{
  "email": "user-b@example.com"
}

{
  "email": "user-b@example.com"
}

The actual value has intentionally been redacted.

And that was the moment the finding became much more interesting.

What's Actually Going Wrong?

Imagine an application has two users:

User A
Phone → 9876543210
Email → usera@example.com
User B
Phone → 9123456780
Email → userb@example.com

User A
Phone → 9876543210
Email → usera@example.com
User B
Phone → 9123456780
Email → userb@example.com

User A makes a request.

The server should derive the identity from the authenticated session:

Authenticated User
       ↓
     User A
       ↓
Check authorization
       ↓
Return User A's information

Authenticated User
       ↓
     User A
       ↓
Check authorization
       ↓
Return User A's information

But if the application instead follows:

Client-controlled phone number
          ↓
      Search user
          ↓
      Find User B
          ↓
 Return User B's information

Client-controlled phone number
          ↓
      Search user
          ↓
      Find User B
          ↓
 Return User B's information

then the authorization boundary has effectively been broken.

The client is influencing which user object the server accesses.

That's the dangerous part.And This Is Why Automation Isn't Everything

Tools are amazing.

I use them.

Recon tools, scanners, fuzzers, crawlers — they can save enormous amounts of time.

But this particular behavior is a good reminder that:

Automation can find patterns. Human curiosity finds logic flaws.

A scanner might tell you:

200 OK

200 OK

But it doesn't necessarily understand:

Why did changing this parameter make the server return another user's information?

Why did changing this parameter make the server return another user's information?

That's where manual testing becomes important.

What I Look For During Authorization Testing

Whenever I find an API that accepts identifiers such as:

user_id
account_id
phone
email
profile_id
customer_id
order_id

user_id
account_id
phone
email
profile_id
customer_id
order_id

I immediately ask:

Who controls this value?

Then:

Does changing it change the object being accessed?

And finally:

Does the server verify that the authenticated user is actually authorized to access that object?

This simple thought process has uncovered a surprising number of access-control issues.

What I Did Next

Once I confirmed the behavior using controlled test accounts, I stopped testing beyond what was necessary to demonstrate the issue.

I did not attempt to collect a database of users.

I did not automate enumeration against the production user base.

I did not access unnecessary personal information.

Instead, I documented the behavior and responsibly disclosed the vulnerability to the appropriate security team.

The report included:

Affected endpoint
Vulnerable parameter
Reproduction steps
Sanitized request/response examples
Security impact
CWE classification
Recommended remediation

The goal of security research isn't to collect someone's data.

The goal is to prove that the data could be exposed and then help make sure it can't be.

Report to Cert-In

Reply from Cert-In

Cert-In Acknowledgement

Final Thoughts

This was another good reminder that you don't always need an advanced exploit to find a serious vulnerability.

Sometimes you just need to look at a request and ask:

"What happens if I change this?"

Then ask the more important question:

"Should I be allowed to change it?"

Broken access control continues to be one of the most interesting areas of web application security because the application can look completely normal while the underlying authorization logic is fundamentally broken.

One parameter.

One request.

One missing authorization check.

And suddenly, another user's information is no longer private.

That's the part that matters.

That's it for this one. 🐝

Keep testing.

Keep learning.

And most importantly

Don't confuse access with authorization.

Cheers and peace out! ✌️

Want to know more about me? Read Here

Want to hack? More Follow Below:

Instagram: @cyberdomy

Eat Well → Hack Well → Snack Well. 🍜💻

Contents