Introduction.

One of the things I enjoy most about bug bounty hunting is how often seemingly minor findings turn into legitimate security issues. Sometimes you don’t need advanced exploitation techniques, complex chains, or zero-days. A simple directory discovery scan can reveal something that was never intended to be publicly accessible.

In this article, I’ll walk through a finding that started with a routine content discovery exercise and ended with an accepted medium-severity vulnerability report and a bounty reward.

Starting With a Single Subdomain.

During a bug bounty assessment, I was exploring an in-scope subdomain belonging to the target program. Like I usually do when approaching a new asset, I began with basic reconnaissance and content discovery.

There’s a reason experienced hunters spend so much time enumerating and fuzzing endpoints. Organizations often secure the applications everyone knows about, but forgotten directories, legacy services, and abandoned resources frequently slip through the cracks.

For this target, I launched ffuf using a raft-medium-sized wordlist and let it do its thing.

Command used.
ffuf -u https://subdomain.target.com -w raft-medium-directory.txt -mc 200,301,302 -fs 0

At first, the results looked fairly ordinary. Most of the responses were either expected directories or redirections. Then one particular endpoint caught my attention:

/files

The response size looked interesting enough to warrant a closer look.

The Unexpected Discovery.

Naturally, I opened the endpoint in my browser.

Instead of receiving a 403 Forbidden response or being redirected to a login page, I was presented with something entirely different.

A file repository.

The page appeared to be powered by a secure, enterprise-grade remote access and control solution used by IT help desks and customer support teams, and displayed a list of files available for viewing and download. Executables, ZIP archives, configuration files, batch scripts, and other resources were all sitting there in plain sight.

My first thought was simple:

“Should this really be accessible to everyone?”

The more I looked at it, the more unusual it seemed. This wasn’t a public download portal. It looked more like a support-related file store that had somehow ended up exposed to the internet.

And perhaps most importantly, there was no authentication required.

Anyone who discovered the endpoint could access it.

Looking Beyond the Files.

One mistake many researchers make is focusing only on whether they can find passwords, API keys, or other obvious secrets.

While those findings are certainly impactful, information disclosure vulnerabilities often provide value in less direct ways.

Even when files do not contain sensitive credentials, exposed repositories can reveal a surprising amount of information about an organization’s environment.

Installers can reveal software in use.

Configuration files can expose deployment details.

Support resources can provide attackers with intelligence that helps them understand internal workflows.

In some cases, such information can even be leveraged for social engineering attacks.

From a security perspective, the bigger issue was not necessarily the contents of a specific file — it was the fact that a repository intended for a limited audience appeared to be publicly accessible.

Putting Together the Report.

After documenting the endpoint and gathering screenshots, I prepared a report explaining the exposure and its potential impact.

The report focused on the lack of access controls surrounding the file store and the information disclosure risks associated with unrestricted access.

I included:

• The vulnerable endpoint.
• Evidence showing public accessibility.
• Screenshots of the exposed file listing.
• A discussion of the security implications.
• Recommendations for restricting access.

Once everything was documented, I submitted the report and waited.

As every bug bounty hunter knows, that’s often the hardest part.

The Verdict.

A few days later, I received an update from the program.

The report had been reviewed and validated.

The security team agreed that the exposed file repository represented a legitimate security issue, and the finding was ultimately classified as a Medium Severity vulnerability.

Even better, the report qualified for a bounty reward.

Why This Finding Matters

What makes this discovery memorable isn’t its technical complexity.

There was no authentication bypass.

No privilege escalation.

No remote code execution.

No elaborate vulnerability chain.

Instead, the finding serves as a reminder that effective reconnaissance remains one of the most powerful skills in bug bounty hunting.

Many researchers rush toward complex attack techniques while overlooking the basics. Yet time and time again, simple content discovery uncovers forgotten assets that organizations never intended to expose.

Sometimes the difference between finding nothing and finding a valid vulnerability is simply taking the time to investigate an interesting response.

Lessons Learned.

This experience reinforced a few important lessons for me.

First, never underestimate directory fuzzing. Even mature organizations can accidentally expose resources that should remain private.

Second, don’t immediately dismiss information disclosure findings. Not every vulnerability needs to leak credentials to create risk.

Third, when something feels out of place, investigate further. The /files endpoint could have easily been ignored as just another directory discovered during fuzzing.

Instead, it turned out to be the source of a valid bug bounty report.

Final Thoughts.

Bug bounty hunting often rewards persistence more than complexity.

This finding began with a single subdomain, a standard FFUF scan, and a bit of curiosity. What seemed like an ordinary directory discovery eventually became an accepted medium-severity report and a bounty payment.

The next time you’re running content discovery against a target, remember that hidden directories are hidden for a reason. Most will lead nowhere. Some will lead to dead ends.

And every once in a while, one of them will lead to a vulnerability worth reporting.

💬 Before You Go.

This finding is a reminder that effective reconnaissance doesn’t always require advanced techniques. Sometimes, a simple content discovery scan is enough to uncover assets that were never intended to be publicly accessible.

The next time you’re fuzzing a target, don’t rush past an interesting response. Take a closer look, investigate further, and understand the context. Hidden directories often tell stories that the main application doesn’t.

Thanks for reading. If you enjoyed this write-up, feel free to leave some claps👏, follow for more bug bounty stories, reconnaissance techniques, and real-world security findings. See you in the next writeup, peace… 🙏