How to Write a Bug Report That Gets Paid
You found a bug. You’re excited. You spend 30 minutes writing a report. Then… nothing. Or worse: “Informational. No bounty.”
It’s frustrating. But here’s the truth most beginners learn too late: finding the bug is only half the job. The other half is writing a report so clear that a triager can verify it in minutes.
Most reports don’t get rejected because the bug is fake. They get rejected because the report is unclear, unreproducible, or technically out of scope.
This guide will teach you exactly how to write a bug bounty report that gets triaged, rewarded, and paid. No fluff. Just practical steps.
Why Most Bug Reports Get Rejected (And It’s Not the Bug)
A triager’s job is to process dozens of reports daily. They are not reading your report to learn about security. They are scanning it to answer three questions:
Is this real? (Can I reproduce it?)
Is this in scope? (Is this asset covered by the program?)
Is this already known? (Has someone else reported this?)
If your report doesn’t answer these fast, it gets pushed to the bottom of the pile—or closed.
The guests on Google’s Cloud Security Podcast said it perfectly: write for the triager, not the product team. The triager doesn’t care about your 2,000-word theory on why the bug exists. They care that it does exist and that they can see it themselves.
Your goal is to make the triager’s life easy. When you do that, they trust you. And trusted researchers get paid faster.
The Anatomy of a Report That Gets Paid
Every high-quality report follows a simple structure. You don’t need fancy templates. You need clarity.
1. Title: Specific, Not Sensational
Bad title: “Critical RCE Found!!!”
Good title: “IDOR in GET /api/v1/invoices/{id} allows any user to read other users’ invoices”
A good title describes what the bug is, where it lives, and what impact it has. That’s it.
2. Summary: The One-Paragraph Pitch
Write 2–3 sentences. Use this formula:
[Who] can [do what] by [how], exposing [what data].
Example from a real IDOR report: “An authenticated user can read any other user’s private conversation history by modifying the conversation_id parameter. The endpoint does not verify ownership, exposing sensitive business and personal data.”
That’s clear. That’s specific. That’s actionable.
3. Steps to Reproduce: Numbered. Exact. Tested.
This is where most reports fail.
Rule: If you can’t reproduce it from your own report, neither can the triager.
Write numbered steps. Include exact URLs, parameters, and values. Use two accounts for authorization bugs (one “attacker,” one “victim”). Label them clearly.
Bad step: “Click the button and see the response.”
Good step: “1. Log in as Account A. 2. Navigate to https://example.com/api/user/123. 3. Change the user ID to 124. 4. Observe that you receive Account B’s private data.”
4. Proof of Concept: Show, Don’t Tell
Include the actual HTTP request and response. Copy from Burp Suite or use curl. Show the sensitive part.
If the bug is visual (like XSS), include a screenshot or short video.
If it’s a logic bug, include a simple script that automates the exploit.
Triagers love PoC that runs. Coinbase’s bounty team emphasizes that a valid proof of concept must be reproducible under real conditions—no over-mocking, no fake test environments.
5. Impact: Why Should They Care?
Don’t just say “this is critical.” Explain what an attacker can actually do.
“Attacker can access 50,000 users’ personal data.”
“Attacker can take over any account without authentication.”
“Attacker can delete other users’ projects.”
Be realistic. Overstating severity hurts your reputation long-term.
6. Severity: Use CVSS (It Shows You’re Serious)
Include a CVSS score with the vector string. You can calculate it free at nvd.nist.gov/vuln-metrics/cvss.
Example: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 7.5 High.
This tells the triager you understand severity classification.
7. Remediation (Optional but Powerful)
Suggest how to fix it. “Implement server-side ownership check on this endpoint.” Triagers appreciate researchers who think like defenders.
Common Mistakes Beginners Make (Avoid These)
Mistake 1: Reporting Out-of-Scope Assets
If the program says *.example.com, don’t report api.example.com unless the program explicitly includes it. Out-of-scope reports get closed instantly and can damage your reputation.
Mistake 2: Submitting Duplicates Without Checking
Before submitting, search the program’s disclosed reports. If it’s already public, it’s a duplicate. You’ll get zero bounty and a small reputation hit.
Mistake 3: “Informational” Findings
Missing security headers? Version disclosure? SPF/DKIM issues? These are almost always informational. They don’t affect the software’s functioning and rarely get paid.
Mistake 4: Emotional or Defensive Writing
Never write “This is obviously a critical bug, why aren’t you paying?” Triagers are humans. Be professional. If a report gets marked duplicate or informational, ask for feedback. Learn. Move on.
Mistake 5: No Clear Reproduction
Again: if it’s not reproducible, it’s not a bug. Test your own steps before submitting. Use a fresh browser or incognito mode to confirm.
The Duplicate Problem (And How to Beat It)
Duplicates are the #1 frustration for bug bounty beginners. Someone always reports it first.
Here’s how to reduce your duplicate rate:
Hunt in the “Seams”
As the Google VRP champions explained, the most profitable bugs live in integrations—where Product A meets Product B. Each product team assumes the other handles security. That gap is your opportunity.
Check Disclosed Reports Before You Test
Spend 20 minutes reading the program’s disclosed reports. You’ll see patterns. You’ll also see what’s already taken.
Submit Fast, But Not Before You Verify
Don’t rush a report. A wrong report wastes everyone’s time. But once you’re confident, submit. Duplicates go to the first eligible submission.
Submit Multiple Findings Together (If Related)
If you find 5 IDOR bugs in the same API, don’t submit 5 separate reports immediately. Submit them together if the program allows. But be careful: some programs treat each endpoint as a separate bug. Read the program rules.
Roadmap: Your Bug Report Action Steps
Follow this checklist before every submission:
Confirm scope. Is the asset explicitly in scope?
Search for duplicates. Check disclosed reports and known issues.
Reproduce the bug 3 times. Use a clean environment.
Write the title. Specific, not sensational.
Write the summary. One paragraph, clear impact.
Write numbered reproduction steps. Exact URLs, parameters, accounts.
Capture PoC. HTTP request/response or video.
Write the impact. Realistic, specific.
Calculate CVSS. Include the vector string.
Review your own report. Can someone else reproduce it from your words alone?
Key Takeaways
Write for the triager. They are scanning, not reading. Make it easy for them to say “yes.”
Reproduction is everything. If you can’t reproduce it, they can’t either.
Be specific in your title and summary. “Critical bug” means nothing. “IDOR in invoice endpoint” means everything.
Impact over hype. Explain what an attacker can actually do. Don’t overstate.
Avoid duplicates by hunting integrations and checking disclosed reports.
Informational findings rarely pay. Focus on bugs that affect confidentiality, integrity, or availability.
FAQ: Bug Bounty Report Writing
Q: How long should a bug bounty report be?
A: As short as possible while being complete. 300–600 words is usually enough. The triager wants clarity, not an essay.
Q: What if my report gets marked “Informational”?
A: It happens. Ask for feedback. Read the program’s rules carefully. Informational findings rarely pay. Focus on higher-impact bugs next time.
Q: Can I submit a bug I found by accident?
A: Yes, if the asset is in scope and the program allows it. But verify scope first. Accidental findings are still findings.
Q: How do I prove a bug without a screenshot?
A: Include raw HTTP requests and responses. A curl command that reproduces the bug is often better than a screenshot.
Q: What’s the fastest way to get my first bounty?
A: Pick a program with a wide scope. Hunt in integrations (where two systems meet). Write a clean, reproducible report. Repeat until you get paid.
Ready to stop guessing and start building your cyber security career?
At Bugitrix, we help beginners get a clear roadmap, real skills, and job-ready confidence through 1:1 mentorship.
👉 Book your 1:1 Cyber Security Mentorship — Click here to apply
👉 Get your Resume & LinkedIn Optimized — Click here to apply
Have questions? Reach us at Info@bugitrix.com or visit bugitrix.com
Further Reading / Resources
Internal (Bugitrix Blog Ideas):
“How to Read a Bug Bounty Program Scope (Without Getting Banned)”
“Your First 30 Days in Bug Bounty: A Beginner’s Roadmap”
“IDOR vs Broken Access Control: What’s the Difference?”
External Authority Links:
OWASP Vulnerability Disclosure Cheat Sheet — guidance on responsible disclosure and reporting
HackerOne Report States — understanding triage, duplicates, and informational
Bugcrowd Getting Rewarded — how valid bugs are validated and paid
CTA Block
Ready to stop guessing and start building your cyber security career?
At Bugitrix, we help beginners get a clear roadmap, real skills, and job-ready confidence through 1:1 mentorship.
👉 Book your 1:1 Cyber Security Mentorship — Click here to apply
👉 Get your Resume & LinkedIn Optimized — Click here to apply
Have questions? Reach us at Info@bugitrix.com or visit bugitrix.com