It's been a while since I last wrote about bug bounty hunting. Over the past few months, I moved to Hyderabad for work and got busy adjusting to a new routine, which meant my bug bounty activity slowed down for a bit. But like many researchers know, once you've experienced the thrill of finding vulnerabilities, it's hard to stay away for long. Eventually, I found myself returning to the hunt and this time, it led to the discovery of a critical vulnerability involving mass exposure of sensitive user data.

In this article, I'm sharing the story of how a deep dive into old reconnaissance data and JavaScript files led me to uncover a hidden attack surface on an unexpected domain. What initially appeared to be a staging environment eventually revealed an Insecure Direct Object Reference (IDOR) vulnerability that exposed highly sensitive personally identifiable information (PII) through an API endpoint.

The vulnerability allowed unauthorized access to sensitive user information including names, phone numbers, addresses, and other confidential details. By manipulating object identifiers within the API requests, it was possible to retrieve records belonging to multiple users, significantly increasing the potential impact of the issue.

What made this discovery particularly interesting was the path that led to it. Instead of traditional manual hunting, the finding emerged from analyzing historical recon data, exploring JavaScript files, identifying an unusual domain discovered during reconnaissance, and leveraging search engine indexing to uncover hidden API endpoints. This highlights how expanding the attack surface through OSINT and creative reconnaissance can often reveal vulnerabilities that automated scans or surface-level testing might miss.

In this article, you'll learn:

  • How analyzing old reconnaissance data can uncover new attack surfaces
  • Why unusual domains discovered during recon can be a gold mine for vulnerabilities
  • How Google dorking helped reveal hidden API endpoints
  • How a simple IDOR vulnerability led to mass PII exposure
  • The importance of intuition and persistence while testing APIs

Let's walk through how this vulnerability was discovered, the testing process that revealed the issue, and the lessons learned along the way.

A Quick Introduction

Before diving into the vulnerability details, here's a brief introduction about who I am.

My name is Mohaseen, and I'm a Cybersecurity Researcher and Bug Bounty Hunter with a strong focus on Web Application Security, Cloud Security, AI Security and Web3 security. I began my journey in ethical hacking and bug bounty hunting in 2019, and since then I've been continuously learning, experimenting, and refining my skills through hands-on, real-world security testing.

Over the years, my vulnerability research and responsible disclosures have earned me multiple acknowledgments, including:

  • 4× Apple Hall of Fame
  • Recognition from several leading global organizations
  • Industry-recognized certifications such as BSCP, eWPTX, eJPT, CRTA, CCSP-AWS, CAPen, and others

Cybersecurity is more than just a profession for me. it's something I'm genuinely passionate about. I enjoy identifying security flaws that are often overlooked and working with organizations to help secure critical systems and protect sensitive user data.

The Bug-How It All Began

After taking a short break from bug bounty hunting due to work commitments and relocating to Hyderabad, I eventually felt the familiar urge to start hunting again. Anyone who has spent enough time in bug bounty knows that the curiosity never really goes away. The moment you stop looking at applications through a security lens, something feels missing.

But this time, I decided to approach things differently.

Instead of jumping straight into manual testing like I usually did, I thought it would be interesting to revisit old reconnaissance data I had collected earlier. Over time, recon scripts gather a huge amount of information domains, subdomains, JavaScript files, endpoints and many of them remain unexplored. Sometimes the real gold is hidden in data you already collected but never deeply analyzed.

So I started digging.

I went through previously collected domains, crawled endpoints, and JavaScript files line by line, trying to understand how the application worked internally. Most of what I found was expected API references, configuration files, standard routes but then something unusual caught my attention.

There was a domain that didn't quite fit the pattern.

For the sake of this article, let's assume the main domain was something like redacted.com. But during reconnaissance, my scripts had discovered another domain: stageredacted.com. What made it interesting was that it wasn't a typical subdomain like stage.redacted.com. Instead, it was a completely separate domain that seemed related to the same ecosystem.

In bug bounty hunting, discovering new or overlooked attack surfaces is like finding a hidden doorway in a building you thought you already mapped completely. Naturally, my curiosity kicked in.

I opened the domain in my browser.

404 Not Found.

At first glance, it looked like nothing. But experienced researchers know that a 404 on an unfamiliar domain can sometimes be a very good sign. It often means the infrastructure exists, but the interesting endpoints are simply not exposed on the root path.

So I started testing.

I tried fuzzing directories, probing for common API routes, checking typical development endpoints, and experimenting with different paths. But after several attempts, nothing particularly interesting appeared. Everything either returned empty responses or the same 404 page.

At that point, many researchers might move on to the next target.

But something about the domain still didn't feel right.

Instead of giving up, I decided to try a different approach search engines.

Search engines sometimes index endpoints that developers never intended to be publicly discoverable. So I ran a simple Google dork:

site:*.stageredacted.com

And that's when things started to get interesting.

A few API endpoints appeared in the search results. They were clearly part of the staging infrastructure and seemed to return test or demo data when accessed directly. I started experimenting with the parameters in those endpoints, modifying values to see how the API behaved.

Initially, the responses only returned sample or demo records. Nothing sensitive, nothing that looked production-related. At first glance, it didn't feel significant enough to report. Many staging environments contain mock data, and this looked like one of those cases.

But then another idea crossed my mind.

What if these same endpoints behaved differently outside the staging context?

Curious, I tried using similar requests against the main production domain. Unfortunately, that didn't work. The responses either returned errors or empty results.

Still, my intuition kept telling me there was something more here.

So I attempted another approach automating the requests across multiple subdomains within the ecosystem. I wrote a quick script to test the endpoints programmatically, hoping that somewhere in the infrastructure the API might respond differently.

But again, nothing worked.

At this point, the easy conclusion would have been that the idea simply didn't work.

However, when I looked closer at my script output, I noticed something small but important: the script was using random or placeholder IDs in the requests. If the API required valid identifiers, that could explain why every request was failing.

So I decided to test it manually.

I replaced the placeholder ID with a real identifier obtained from the main application and replayed the request.

And that's when everything changed.

One of the API endpoints on a specific subdomain suddenly responded with a full JSON response containing real user data. Not demo data. Not sample records.

Actual production information.

The response included highly sensitive personally identifiable information (PII) such as user names, phone numbers, addresses, identification numbers, card-related details, and more.

For a moment, I just stared at the screen.

This wasn't just a staging data leak. It was a broken object-level authorization (IDOR) vulnerability allowing access to real user records.

And if the endpoint was vulnerable to ID manipulation, the next question became obvious:

How much data could be accessed?

That's when the true scale of the vulnerability began to reveal itself.

Confirming the Impact — And the Unexpected Ending

At this point, the situation became very clear: this wasn't just a staging environment exposing harmless demo data. The API was returning real production user information, and it was doing so without enforcing proper authorization checks.

However, before jumping to conclusions, I needed to carefully confirm the impact.

The request that returned the sensitive data contained a numeric identifier parameter. If this was truly an IDOR (Insecure Direct Object Reference) vulnerability, then modifying that identifier could potentially return records belonging to other users.

To validate this, I intercepted the request and sent it to Burp Suite Intruder, configuring a small range of identifiers to test how the API would behave. Instead of scanning aggressively, I started with a limited range from xxx00 to xxx99 just enough to observe whether the endpoint was vulnerable.

Very quickly, the responses made the problem obvious.

Each request returned a different user's record.

The API was exposing highly sensitive personally identifiable information (PII) including:

  • Full names
  • Phone numbers
  • Residential addresses
  • Identification numbers
  • Card-related details
  • And other confidential user information

There were no authorization checks in place. As long as a valid identifier was supplied, the API simply returned the associated user's data. This meant an attacker could potentially automate requests and retrieve large volumes of sensitive user information.

In other words, this wasn't just a small information disclosure it was a mass PII exposure vulnerability caused by Broken Object Level Authorization (BOLA / IDOR).

On this particular bug bounty program, vulnerabilities involving large-scale exposure of sensitive user data typically fell under P1 severity, with bounty rewards going as high as $20,000. Naturally, I carefully documented the findings, captured the proof-of-concept requests and responses, and prepared the report for submission.

Once everything was ready, I submitted the vulnerability report to the program.

Interestingly, within about four hours, the issue was fixed.

At first, I assumed the quick response meant the report had been triaged and the security team had acted immediately to patch the vulnerability. But when I later received the response from the program, the situation turned out to be slightly different than expected.

According to their reply, the internal security team had already detected unusual activity related to the endpoint through their SOC monitoring systems and had started investigating the issue before my report was submitted. Looking back, it's quite possible that the burst of requests generated during my Burp Intruder testing triggered the alert that led their team to identify and fix the vulnerability quickly. Since the fix was already deployed by the time they reviewed my submission, they were unable to reproduce the issue from my report.

As a result, the report was closed without a bounty payout.

So while the vulnerability itself had the potential to be a $20,000 P1 issue, the final reward ended up being $0.

While that might sound frustrating, this experience also highlighted an important reality of bug bounty hunting: sometimes you can discover a critical vulnerability, confirm its impact, and still not receive a bounty if the issue has already been internally identified or fixed before the report is processed.

And that's simply part of the game.

The Lesson

This finding reminded me that some of the most interesting vulnerabilities appear when you start exploring areas that others might ignore. In this case, it all started with an unusual domain discovered during reconnaissance and a bit of curiosity while digging through old data. Expanding the attack surface and trusting your intuition often leads to unexpected discoveries.

It also highlights an important reality of bug bounty hunting sometimes you can discover a serious issue and still walk away with no bounty because of timing or internal detection. While it can be frustrating, every such experience adds to the learning process and sharpens your approach for future hunts.

Also, I'm currently based in Hyderabad, so if anyone wants to connect physically, talk about bug bounty, cybersecurity, or just share war stories about missed bounties, feel free to reach out. Always happy to connect with fellow researchers.

If you enjoyed this article and want to collaborate on bug bounty research or security projects.

Connect with me: