Introduction

Hello Hunters, I'm ANONDGR, and welcome back to another real-world bug bounty POC breakdown.

This write-up is not about bypassing WAFs, chaining vulnerabilities, or exploiting complex attack paths. Instead, it's about spotting a simple but dangerous business logic flaw caused by broken access control—the kind of issue scanners usually miss but companies genuinely care about.

During my hunt on a large financial services company's bug bounty program, I discovered a vulnerability in their partner onboarding system that allowed pre-registration of legitimate users using fake details, effectively locking real users out of the program.

This report was rewarded with ₹15,000, and in this blog, I'll break down how I found it, why it mattered, and what beginners can learn from it.

Target Overview

  • Program Type: Private Bug Bounty
  • Target: Partner Onboarding Portal
  • Scope: Wildcard Web Assets
  • Category: Business Logic / Access Control
  • Severity: P4 (Impact-Based)

The application was a partner registration portal used by existing customers of the company to enroll in a referral/partner program.

No authentication was required to access the registration flow—which is normal for onboarding—but what wasn't normal was how much the backend trusted user input.

Initial Observation

While testing the registration process, I noticed that all partner onboarding requests were handled by a single backend API endpoint:

POST /api/register/

This endpoint accepted a client_id parameter directly from user input.

For a financial platform, A represents a real, KYC-verified customer. So the obvious question came to my mind:

What happens if someone submits a valid client ID that doesn't belong to them?

That question alone led to the entire vulnerability.

Testing the Registration API

I started sending registration requests manually and carefully observed how the server responded.

Here's what stood out immediately:

  • No authentication required
  • No ownership verification of client_id
  • No validation against actual KYC records
  • No rate limiting or abuse protection

The API accepted any data I submitted, as long as it client_id was valid.

That meant I could submit:

  • fake PAN numbers,
  • fake bank account details,
  • fake addresses,
  • fake email IDs and phone numbers,

and the server would still respond with a successful registration reference number.

No warnings. No checks. No friction.

None

By doing this, I have registered 2000+ fake user's within few minutes

None

Client ID Enumeration

To understand the scope, I tested how client_id values were structured.

After a bit of experimentation, I noticed that client IDs followed predictable and sequential patterns.

Even worse, the API behaved differently when:

  • an invalid client ID was supplied, versus
  • a valid but unused client ID.

This made it trivial to enumerate valid client IDs just by observing response differences.

Using Burp Intruder, I tested ranges like

XX0000 → XX0999
YY1000 → YY1999

There was:

  • no blocking,
  • no CAPTCHA,
  • no rate limiting.

This meant the issue was fully automatable.

None

Because I already have figured out the Client ID format by looking into the source code 😜

Why This Was a Real Business Impact

This wasn't just about fake registrations.

1. Locking Out Legitimate Users

By preregistering a valid client ID with fake data:

  • the real customer would later be unable to register correctly.
  • they would be forced to contact support for manual resolution.
  • and their onboarding experience would be broken.

This is a persistent denial of service against legitimate users.

At scale, thousands of users could be affected.

2. Partner Incentive & Impersonation Risk

Once fake details were accepted:

  • incentives,
  • commissions,
  • or partner rewards

could potentially be misused by an attacker impersonating the real client.

Even if not immediately exploitable, this creates a trust failure in the onboarding system.

3. Reputation & Operational Impact

For a financial company, onboarding integrity is critical.

Mass abuse of this endpoint would:

  • overload customer support,
  • damage brand trust,
  • and potentially lead to regulatory scrutiny.

This is exactly why business logic flaws matter, even when they're not labeled P1 or P2.

Why Scanners Would Never Find This

There was:

  • no SQL injection,
  • no XSS,
  • no authentication bypass.

The flaw existed because:

  • the system trusted user input blindly, and
  • Therethere was no ownership verification for a sensitive identifier.

This is a classic broken access control and business logic vulnerability.

Only manual testing and critical thinking can uncover these issues.

Reporting & Outcome

I reported the issue responsibly with:

  • clear reproduction steps,
  • realistic abuse scenarios,
  • and a business-focused impact explanation.

The security team acknowledged the concern and decided to:

  • introduce additional protection mechanisms (like CAPTCHA),
  • and treat the report as valid based on the risk discussion.

The vulnerability was closed, and I received a ₹15,000 bounty for the finding.

None

Key Lessons for Beginners

If you're starting out in bug bounty, take this with you:

  • High impact ≠ always high severity labels
  • Business logic bugs pay real money
  • Predictable identifiers are dangerous
  • Missing validation can be worse than missing auth
  • Always ask, "What happens if I misuse this flow?"

This entire bug came from one simple thought:

"What if this ID isn't mine?" 😜

Final Words

This vulnerability wasn't flashy. It wasn't complex. It wasn't too heavy.

It was about understanding how systems are supposed to work—and finding where they don't.

If you're tired of scanning and getting nowhere, start focusing on:

  • trust assumptions,
  • missing ownership checks,
  • and business workflows.

That's where real bugs live.

Happy Hunting 🐞 — ANONDGR