I Read 100 Bug Bounty Reports on HackerOne — Here’s What Separates $50 Bugs From $10,000 Ones

Two hunters find the exact same IDOR. One gets $50 and a "Low" severity label. The other gets $8,000 and a personal thank-you from the CISO.

Same bug class. Same platform. Sometimes even the same company, months apart.

I spent weeks going through 100 disclosed and private reports across programs of different sizes — fintech, SaaS, e-commerce, and a couple of crypto platforms — to figure out what actually separates the bounties that get lowballed from the ones that get paid out big. This isn't a "10 tips to find bugs faster" post. It's a breakdown of the report itself — because I kept seeing the same thing: the vulnerability was rarely the variable. The report was.

Here's the methodology, the patterns, and the exact things you can change in your next report today.

The Methodology

I didn't just skim these reports. For each one, I logged:

• Vulnerability class (IDOR, XSS, SSRF, auth bypass, business logic, RCE, etc.)
• Reported severity vs. final severity (did triage downgrade or upgrade it?)
• Bounty amount
• Report structure (was there a summary, impact section, PoC, remediation?)
• Time to triage (how fast did the team respond?)
• Number of back-and-forth comments before resolution
• Whether the hunter demonstrated real-world impact or just "technical" impact

I grouped reports into three buckets: under $100, $100–$1,000, and $1,000+. Then I looked for what correlated with landing in the top bucket, independent of the raw vulnerability class.

The result surprised me a little. I expected "harder bugs = more money," which is true but incomplete. The bigger driver was how well the hunter proved the bug mattered.

Finding #1: Low-Paying Reports Describe the Bug. High-Paying Reports Describe the Damage.

This was the single biggest differentiator, by far.

The $50 pattern:

"The endpoint /api/user/update does not validate the user_id parameter, allowing a user to modify another user's profile."

Technically correct. Completely unpersuasive. A triager reading dozens of these a day sees "IDOR, profile edit" and mentally files it under low severity before finishing the sentence.

The $5,000+ pattern:

"By modifying the user_id parameter on /api/user/update, an attacker can change the email address on any account, including admin accounts. Combined with the password reset flow, this allows full account takeover of any user on the platform, including support staff with access to customer PII."

Same root cause. Completely different framing. The second report didn't just find a bug — it built a story of consequence: what an attacker could actually do, and to whom.

Practical takeaway: Before you submit, ask yourself: "If I were the CISO, would this sentence make me nervous?" If the answer is no, keep digging into impact before you write the report.

Finding #2: The Best Reports Chain the Bug to a Business Outcome, Not Just a Technical One

Programs don't pay for CVSS scores. They pay for risk to the business.

Reports that scored well consistently translated technical impact into one of these categories:

• Financial loss (fraud, free purchases, discount abuse, payment bypass)
• Data breach (PII, credentials, internal documents)
• Account takeover (especially of privileged or admin accounts)
• Reputational/compliance risk (GDPR, HIPAA, PCI exposure)
• Availability/DoS on revenue-generating flows

A CSRF on a "change display name" feature and a CSRF on a "change payout bank account" feature might both be textbook CSRF. One is a $100 bug. The other is a $6,000 bug — because one touches money.

Practical takeaway: When you find a vulnerability, don't stop at "I can do X." Ask "What does X let me steal, break, or bypass — and how much does that cost the business if exploited at scale?" Explicitly name the business consequence in your report title and summary, not buried in paragraph four.

Finding #3: PoC Clarity Was a Bigger Bounty Driver Than PoC Complexity

I expected complex, multi-step exploit chains to dominate the top bucket. Some did. But a huge number of $1,000+ reports had simple vulnerabilities with exceptionally clear proof-of-concept.

The pattern in weak PoCs:

• A single screenshot with no annotation
• A Burp request dump with no explanation of what to look at
• "Steps to reproduce" that assume the triager already knows the app as well as the hunter does

The pattern in strong PoCs:

• Numbered steps, each one action only
• A short screen recording (even 20–30 seconds) showing the exploit from a logged-out or low-privilege state to the final impact
• curl commands or a minimal script that reproduces the bug in under 60 seconds, with placeholders clearly marked
• A one-line "TL;DR" impact statement before the technical steps, so a busy triager gets the point in 5 seconds

One thing I noticed repeatedly: hunters who included a video PoC got faster triage times and, on average, higher final bounties than those who used screenshots alone — even for bugs of similar technical severity. Triagers manage huge queues. A video that proves the exploit in 30 seconds removes all doubt and cuts the back-and-forth to zero.

Practical takeaway: Structure every PoC as: (1) one-sentence impact statement, (2) numbered reproduction steps, (3) visual evidence (video > annotated screenshots > raw request dump), (4) exact request/response pairs for the technical reviewer who wants to verify it manually.

Finding #4: Reports That Got Downgraded Almost Always Had a Missing "Why This Matters at Scale" Section

I specifically tracked reports where the hunter's suggested severity was higher than what the program finally paid. In nearly every one of those cases, the report was missing an explicit answer to: "Can this be automated or exploited against multiple users?"

A rate-limit bypass on a single login form reads very differently depending on whether you say:

• "I was able to bypass the rate limit" (sounds minor)
• vs. "I automated this bypass and successfully brute-forced 40 test accounts in under 3 minutes using the attached script, meaning an attacker could credential-stuff the entire user base" (sounds like a real incident)

Practical takeaway: Wherever plausible and ethical, actually demonstrate scale — within the program's rules of engagement. Even a small-scale, clearly-labeled test against your own test accounts (never real user data) shows the reviewer the ceiling of the risk instead of making them imagine it.

Finding #5: Response Time and Tone in the Back-and-Forth Correlated With Final Payout

This one is less about the report and more about what happens after you hit submit. Reports where the hunter responded to triager questions within a few hours, stayed technical and non-defensive, and provided any requested clarification quickly were resolved faster and, on average, paid better than reports where the hunter went quiet or got combative when severity was questioned.

Security teams remember hunters. The ones who communicate like a professional colleague instead of someone trying to "win" an argument get the benefit of the doubt on borderline severity calls — and get invited to private programs, which is where the real money is.

Practical takeaway: If a triager pushes back on your severity rating, don't argue — provide more evidence. "Here's a video showing this against an admin account" beats "this should clearly be Critical" every time.

The Report Template That Kept Showing Up in Every High-Paying Submission

After going through all 100, the consistent skeleton looked like this:

1. Title — names the impact, not just the bug class (e.g., "Account Takeover via Email Change IDOR" not "IDOR in /api/user/update")
2. TL;DR / Impact Summary — 2–3 sentences, written for someone who will read it in 10 seconds
3. Vulnerability details — the technical root cause, plainly explained
4. Steps to Reproduce — numbered, minimal, one action per step
5. Proof of Concept — video/screenshots + raw request-response
6. Business Impact — explicit: money, data, accounts, compliance
7. Suggested Fix — even a one-line suggestion shows maturity and separates you from spray-and-pray hunters
8. CVSS or severity justification — tie your rating to a specific scoring vector, don't just assert it

Hunters who used something close to this structure consistently landed in the top bucket, regardless of program size.

The Real Takeaway

The gap between a $50 bug and a $10,000 bug is rarely a 200x difference in technical skill. It's usually the difference between a hunter who reports what they found and a hunter who reports what it means.

Triagers aren't grading your hacking skills. They're assessing risk to a business, on a deadline, with a queue of 40 other reports waiting. The hunter who makes that job easy — clear impact, clear proof, clear business consequence — gets rewarded for it, every time.

If you take one thing from this breakdown: stop submitting the moment you find the technical bug. Spend the next 20 minutes proving why it matters. That's usually where the extra zero on your bounty comes from.

Want help applying this to your own reports?

I run Bugitrix, and this kind of report-quality breakdown is exactly what we work on with hunters 1:1 — reviewing real submissions, fixing impact framing before you hit submit, and building the habits that separate consistent earners from one-off lucky finds.

• 1:1 Mentorship (report reviews, methodology, live bug hunting sessions): Apply here
• Resume, LinkedIn & Portfolio Building for security roles: Apply here
• Free daily tips and resources on our Telegram: t.me/bugitrix
• More on what we do: bugitrix.com

If this breakdown helped you rethink how you write reports, the best thing you can do is go rewrite your next submission using the template above — and let me know how the bounty compares.