🧠 The Hunt Begins

Bug hunting is often a mix of patience, frustration, and those rare moments where everything suddenly clicks.

This story is about one of those moments.

I was exploring a target on Bugcrowd, a fairly large web application with multiple subdomains. Like any hunter, I started mapping the surface area, checking endpoints, and digging into JavaScript files.

That's when I found something interesting.

🔍 The First Clue: Internal API Exposure

While analyzing the JS files, I stumbled upon an endpoint:

/api/internal/user/InternalUser

At first glance, this didn't look like something meant for public access.

But curiosity wins in bug hunting. 😝

When I interacted with it, it returned sensitive internal data — including:

  • Admin emails
  • Usernames

💥 That's already a red flag.

None

😤 The Frustration Phase

At this point, I had valid admin usernames and emails.

But no password.

And without credentials, it felt like hitting a wall.

I tried multiple angles:

  • Parameter manipulation
  • Direct authentication attempts
  • Token guessing

Nothing worked.

That's when I stepped back and thought:

"What if I don't need the password at all?"

💡 The Breakthrough: Password Reset Abuse

Instead of attacking login directly, I shifted focus to the password reset functionality.

The endpoint looked like this:

/api/public/memberauth/password/forgot/init

Attempt 1: HTTP Parameter Pollution

I tried a classic trick:

/api/public/memberauth/password/forgot/init?username=9299393388&email=victimemail@gmail.com,myemail@gmail.com

The idea was simple:

Maybe the system will send the reset link to both emails.

But… no luck. 😑

None

🧪 Attempt 2: Direct Email Injection

Then I tried something simpler.

I replaced the victim's email with my own email:

username = victim_admin_username  
email = myemail@gmail.com

I sent the request…

And the response came back:

"status": "ok"

🤔 That was… suspicious.

📩 The Moment Everything Changed

A few seconds later…

📥 I received a password reset email.

For the admin account.

None

🚪 From Reset to Access

I followed the reset link.

Set a new password.

Tried logging in…

And just like that —

I was inside the admin account.

None

⚠️ Root Cause Analysis

This vulnerability was a combination of two critical issues:

1. IDOR (Information Disclosure)

  • Internal API exposed admin emails and usernames
  • No proper access control

2. Broken Password Reset Logic (ATO)

  • Backend trusted user-controlled email parameter
  • No verification that email belongs to username
  • Allowed attacker to redirect reset link

💥 Impact

This wasn't just a bug.

This was a full Admin Account Takeover (ATO).

An attacker could:

  • Access admin panel
  • Modify system configurations
  • View sensitive user data
  • Potentially pivot deeper into infrastructure

🧠 Key Takeaways

  • Never expose internal APIs without authentication
  • Always validate ownership in password reset flows
  • Don't trust client-supplied email parameters
  • Small leaks (like emails) can lead to massive impact

🎯 Final Thoughts

This bug taught me something important:

Sometimes the fastest way in… isn't breaking the door. It's asking the system to open it for you.

Connect me:

X: https://x.com/wanahmadqais007