From N/A to ##,###$: How I Turned One Overlooked Bug Into a Major Security Finding in a HackerOne…

Disclaimer:_ This article has been anonymized to protect the affected organization. Certain technical details, infrastructure identifiers, and sensitive information have been intentionally omitted or modified. The vulnerability was reported responsibly through the company's bug bounty program and remediated by the security team._

Introduction

Every bug bounty hunter has experienced it.

You spend hours investigating a target, discover what appears to be a serious vulnerability, submit a detailed report, and then receive the response nobody wants to see:

For many researchers, that's where the story ends.

For me, it was only the beginning.

This article tells the story of how a report that was initially closed as N/A eventually became one of my most rewarding bug bounty findings, not because I discovered another vulnerability, but because I took the time to understand the true impact of the first one.

The biggest lesson I learned is simple:

Finding a vulnerability is only half the job. Demonstrating its real-world impact is what creates value.

I'm Sajad Alaskare, a cybersecurity researcher and founder of Cyber Command. In this article, I'll share the story of how a bug that was initially closed as "Out of Scope" eventually became one of my highest-impact bug bounty findings.

The Initial Discovery

While testing a target in h1 bug bounty program, I came across what appeared to be a straightforward Server-Side Request Forgery (SSRF) vulnerability.

The vulnerable endpoint allowed me to make simple arbitrary server-side requests. At first glance, it looked like a solid severity finding, so I documented the issue with a detailed proof of concept and submitted my report.

I was confident it would be accepted.

A few hours later, I received a notification.

The report had been closed.

Reason: Out of Scope.

The vulnerable asset wasn't listed in the program's scope, so despite the technical impact, the report was marked N/A (Not Applicable).

Like many researchers, I was disappointed. Hours of research had resulted in nothing.

But instead of forgetting about the report, I politely asked the triage team to make sure the finding reached the internal security engineers because I believed the vulnerability affected shared infrastructure rather than just a single website.

To my surprise, the report was reopened.

A few days later, after the security team reviewed the issue internally, the report was accepted and rewarded with #,###$, despite originally being closed as out of scope.

Most people would have celebrated and moved on.

I didn't.

Going Back to the Vulnerability

Receiving the bounty made me think about something.

If this SSRF was powerful enough to convince the security team after initially being rejected, what else could it reach?

I reopened my notes and started looking at the vulnerability again, this time with a different objective.

Not to prove SSRF existed.

To understand everything that SSRF could access.

Instead of testing random endpoints, I started mapping the internal environment, identifying accessible services, private networks, and cloud infrastructure.

Every response revealed another piece of the puzzle.

The vulnerability was much bigger than I initially thought.

Following the Trust Chain

Modern cloud environments are built on trust.

Applications trust internal APIs.

Internal APIs trust configuration files.

Configuration files trust cloud credentials.

Cloud credentials trust backend services.

Breaking just one link can expose everything behind it.

During my research, I discovered that the SSRF could reach internal resources that were never intended to be exposed externally.

Among those resources were configuration files containing sensitive backend credentials.

At that moment, the vulnerability stopped being "just an SSRF."

It became an authenticated attack chain.

The Second Investigation

Rather than ending the research after finding exposed credentials, I wanted to understand their actual impact.

Using only the minimum amount of interaction required for validation, I confirmed that the credentials were accepted by internal production services.

The vulnerable application effectively became a bridge into trusted infrastructure.

What originally started as an unauthenticated SSRF had evolved into authenticated access to internal systems.

This completely changed the security implications of the report.

The attack chain now demonstrated how a single public vulnerability could lead to access across multiple layers of production infrastructure.

Updating the Report

I returned to my report with new evidence.

Instead of describing an SSRF that could reach internal hosts, I documented an attack chain showing authenticated access obtained through resources exposed by the vulnerability itself.

The report no longer described a theoretical risk.

It described a practical compromise path.

The security team reviewed the additional findings and reassessed the impact.

The bounty increased again.

The same report that had originally been marked N/A had evolved into one of my most significant bug bounty findings.

What This Experience Taught Me

This experience completely changed how I approach bug bounty hunting.

Many researchers stop when they find a vulnerability.

The real value comes from understanding what that vulnerability enables.

An SSRF is rarely just an SSRF.

An IDOR is rarely just an IDOR.

The first bug is often only the entry point to a much larger story.

The researchers who consistently find high-impact vulnerabilities are usually the ones who ask one simple question:

"What happens if I keep following the chain?"

Final Thoughts

If I had accepted the initial Out of Scope decision and moved on, this story would have ended with an N/A report.

If I had accepted the initial bounty and stopped researching, I would never have discovered the much larger impact hidden behind the original vulnerability.

Persistence, curiosity, and responsible investigation transformed a rejected report into a major security finding.

Sometimes the difference between an ordinary bug report and an extraordinary one isn't finding another vulnerability.

It's refusing to stop investigating the first one.