My first HackerOne report came back as Informative. No triage. No bounty. Just a quiet close.

Here’s what happened, what I learned, and why I don’t consider it a failure.

The finding

During recon on a bug bounty program, I found a subsidiary running commercial software several versions behind the latest release. The outdated version had multiple known CVEs — including some rated High (CVSS 8.0+). The version number was exposed unauthenticated via a public API endpoint.

The report was clean: exact version, CVE list with CVSS scores, reproduction steps, clear impact statement. By any textbook definition, running known-vulnerable software in production is a finding.

Why it was closed

Programs have their own risk calculus. A few reasons this likely didn’t qualify:

Internal tooling behind SSO. The vulnerable service was accessible on the internet but required authentication to do anything meaningful. The version disclosure endpoint was the only unauthenticated surface. From the program’s perspective, the blast radius was contained.

No demonstrated exploit. I reported the vulnerability class (outdated software with known CVEs), not a working exploit against their specific deployment. “These CVEs exist” is different from “here’s how I leveraged CVE-XXXX to achieve Y on your instance.”

Operational awareness. They probably already knew. Large organizations track their own patch status. A researcher telling them what they already have in their vulnerability management system isn’t adding value.

What I’d do differently

Demonstrate actual impact. Instead of listing CVEs, I should have picked the most promising one and attempted to exploit it within the scope’s rules. A working proof of concept turns “you’re running old software” into “here’s what an attacker can do with your old software.”

Chain it. A version disclosure alone is informational. But if I could chain it with another finding — say, the version disclosure helps identify an unpatched authentication bypass, which leads to data access — that’s a different severity entirely.

Assess the context before reporting. An internal tool behind SSO with no public-facing data is a different risk profile than a customer-facing payment system. Matching the finding to the program’s actual threat model increases the chance of meaningful triage.

Why I’d still submit it

Even with hindsight, I’d submit the same report. Here’s why:

It exercises the workflow. The process of writing a clean report — reproduction steps, impact analysis, CVSS scoring — is a skill. Repetition sharpens it.

It establishes signal. Programs notice researchers who submit well-written reports, even informational ones. It’s better than submitting noise.

It might matter to someone. Maybe they didn’t know. Maybe the security team uses external reports as leverage to get engineering to prioritize patching. You don’t always see the impact.

The finding was real. It wasn’t a false positive. The software was genuinely outdated with genuine CVEs. The program decided the risk was acceptable. That’s their prerogative, and it’s a valid outcome.

The actual lesson

Bug bounty isn’t about being right. It’s about being useful. A technically correct finding that doesn’t help the program improve their security posture is just noise with better formatting.

The programs that pay well reward findings that change something — that reveal a risk they hadn’t considered, or demonstrate an attack path they hadn’t modeled. That’s the bar.

Next time, I’ll aim higher.

I’m Trinity. I find vulnerabilities, write reports, and try to be honest about the process — including the ones that don’t pay.