How I Exploited a Business Logic Flaw to Change Phone NumbersWithout Support

3 min readSep 11, 2025

Bug bounty hunting is not always about SQL injections or RCE. Sometimes, the most impactful findings come from business logic flaws — cases where the system behaves exactly as coded, but not as intended.

In this writeup, I’ll share how I discovered a flaw in a private bug bounty program that allowed me to change my account’s phone number without any support team approval, simply by manipulating API logic.

Initial Observation

After signing up and logging into my account, I noticed something interesting:

During registration, users are asked to add a phone number.
But once the account is created, there is no option to change the number from the profile page.
The platform clearly stated: To update your phone number, please contact support.

At first, this looked like a strict design choice, but I decided to investigate further.

Burp Suite Recon

While reviewing my Burp Suite history, I noticed an endpoint:

/withoutnumber

This appeared to handle number assignments during the onboarding flow.

Curious, I decided to test it manually.

First Attempts

I tried to send a request to this endpoint with a different number. The server replied:

403 Forbidden

At this point, many would stop. But I knew this kind of response often means “you’re close, but not quite right.”

The Endpoint Discovery

On a hunch, I changed the endpoint from:

/withoutnumber

/withnumber

Now things started to get interesting.

Method & Parameter Manipulation

Next, I experimented with the request method. The UI originally sent it as a POST, but I switched it to PUT.

Then, I added a JSON body parameter:

{
  "phone": "+49XXXXXXXXX"
}

The Breakthrough

To my surprise, the server accepted the request and updated my phone number instantly — no support team, no OTP verification, no warnings.

The workflow intended by the platform was completely bypassed.

Why This is a Business Logic Flaw

This wasn’t about injecting malicious payloads. Instead, it was about thinking differently about the system’s logic:

The frontend restricted users from updating their number.
But the backend API had no proper authorization or validation checks.
By discovering the right endpoint (/withnumber) and tweaking the HTTP method (PUT instead of POST), I could achieve what should have been impossible.

This is a textbook case of a Business Logic Bug + IDOR (Broken Access Control).

Impact

Users could freely update their phone numbers without contacting support.
If exploited maliciously, an attacker with temporary access to an account could replace the victim’s phone number with their own, potentially hijacking MFA or account recovery.
It undermines the integrity of identity verification on the platform.

Lessons Learned

Business logic flaws are subtle but powerful. Always question what the app expects vs. what the server enforces.
Don’t ignore odd endpoints. /withoutnumber → /withnumber might look trivial, but small variations often reveal hidden functionality.
Try different HTTP verbs. Switching from POST to PUT was the key to triggering the vulnerable workflow.

Conclusion

This bug was reported responsibly to the program, triaged as a valid business logic vulnerability, and highlighted the importance of server-side validation.

It’s a reminder that in bug bounty, success often comes not from flashy exploits, but from careful observation, curiosity, and a willingness to test assumptions.

Rijuljenjen