As a bug hunter, I’ve learned that the simplest interfaces can sometimes hide the biggest mistakes. A single API request. One unprotected parameter. That’s all it takes to turn a quiet web page into a goldmine of sensitive data.

While exploring an application during a recent bug hunting session, I stumbled across something that seemed almost too open. No login prompt, no token, no access control. Just a lone endpoint quietly giving out user data to anyone who asked nicely.

What started as a routine recon session quickly turned into a serious information disclosure bug, leaking full user profiles, including emails, phone numbers, and admin flags, all without authentication.

Here’s how it happened.

1. Reconnaissance

Like most of my bug sessions, this one started with some routine recon. I fired up Subfinder, as I always do, and let it do its thing. It’s a ritual by now. Once the results were in, I focused on subdomains that returned a clean 200 OK. I tend to start with those before diving into redirects or more obscure status codes.

One of the domains I landed on greeted me with a login prompt. Seemed standard at first, but I decided to dig a little deeper. I ran a directory and file scan on the host and found a handful of endpoints returning 200 OK. That’s when things started to get interesting.

Accessing one of these endpoints didn’t give me much at first glance, but it appeared to create an anonymous session behind the scenes. Suddenly, I could browse parts of the application without logging in. There were pages to create tickets, view profiles, and other internal functionality. Everything looked blank, with fields empty or missing entirely, but the fact that I could even see this interface without authenticating caught my attention immediately.

2. Exploration

With access to parts of the application through an anonymous session, I shifted gears. I began clicking through every button, tab, and link I could find. My goal was to map the attack surface as thoroughly as possible. Even if the pages were empty, their presence alone could reveal hidden functionality or misconfigurations.

It didn’t take long before something stood out. Within the interface, I found a feature to create a new ticket. Nothing unusual there. But what caught my eye was an additional option: a button labeled something like “Include Users.”

Curious, I clicked it.

The request went out. The page loaded. But just like the rest of the app, the response was blank. No users, no error, just silence. At first, it seemed like a dead end: maybe the feature was restricted, or maybe the session simply wasn’t allowed to access user data.

But blank responses aren’t always the end of the story. Sometimes, they’re just hiding something waiting to be discovered.

3. Exploitation

While watching the network traffic in Burp Suite, one particular request stood out. It was triggered when I clicked the Include Users button, and it looked something like this:

GET /tasks/task?handler=Users&factoryId=0 HTTP/1.1
Host: localhost:3000

The presence of the handler=Users parameter immediately raised a red flag. Even though the response returned nothing, it was clear the application was trying to fetch user data. It was just scoped to factoryId=0, probably due to the anonymous session that had been created earlier.

That caught my attention.

I started modifying the factoryId parameter manually and replayed the request through Burp. To make things easier, I filtered responses based on length, looking for anything that wasn't the usual empty response. It didn’t take long.

One of the responses came back significantly larger.

Opening it revealed full user records:

Names, emails, phone numbers, titles, admin flags, and more. All of it was being returned to an unauthenticated user, just by changing a number in the request parameter.

At that point, it was clear what I had found.

4. Responsible Disclosure

As soon as I confirmed the impact of the vulnerability, I reported it through the proper disclosure channel without delay. The triage team responded quickly and professionally, acknowledging the issue within hours.

What really impressed me was how fast they moved. The vulnerability was confirmed, patched, and fully resolved in just two days. The endpoint was secured, and access controls were properly enforced to prevent any further unauthorized access to user data.

It’s always satisfying to see a fast and effective response to a report, and this was a great example of how well-handled disclosure can improve the security of an application for everyone.

Every bug has a story. This one started with a simple button and ended with a serious vulnerability. It’s a good reminder that sometimes all it takes is a small curiosity to uncover something much bigger.