Bug Bounty Report Template That Gets Paid (With Examples)

A bug bounty report template can mean the difference between a $500 payout and a “not applicable” response. Most bounty hunters find real vulnerabilities, but they write reports that get deprioritized because they lack structure, proof of impact, or clear reproduction steps.

We analyzed dozens of publicly disclosed bug bounty reports across HackerOne and Bugcrowd to identify what separates reports that get triaged in 24 hours from those that sit for weeks. The pattern is clear: format matters as much as the finding itself.

What Makes a Bug Bounty Report Get Paid

Triage teams on platforms like HackerOne and Bugcrowd review dozens of submissions per day. They spend roughly 30 seconds deciding whether a report deserves a closer look or gets closed as “not applicable.”

The First 30 Seconds of Triage

The HackerOne quality reports guide  lays out what triagers check first:

1. Is it in scope? If the asset or vulnerability type is not in the program scope, it gets closed immediately.
2. Is there a clear proof of concept? A report without evidence is a report without priority.
3. Is the impact stated explicitly? “This is an XSS” is not enough. “This stored XSS allows session hijacking for any logged-in user” gets attention.

Proof of Impact vs. Theoretical Impact

The number one reason bug bounty reports get rejected (beyond scope issues) is theoretical impact. Saying “an attacker could potentially access user data” without demonstrating the exploit path tells the triage team you have not validated your finding.

Show, do not speculate. If you found an IDOR, show the data you accessed. If you found an XSS, show the payload executing. If you found an authentication bypass, show the authenticated session.

The difference between a paid report and a rejected one often comes down to a single HTTP response. Include the response body that proves your exploit worked. A triage analyst who can see the proof does not need to reproduce the vulnerability themselves to escalate it.

CVSS Scoring Basics for Bounty Hunters

Most platforms use CVSS (Common Vulnerability Scoring System) to standardize severity. Use the CVSS calculator  to score your finding before submitting.

A justified CVSS score shows professionalism. It also prevents the triage team from downgrading your severity because you described a “critical” bug that scores as a medium on the scale.

Pay attention to the attack complexity (AC) and privileges required (PR) fields in particular. An XSS that requires social engineering to trigger scores differently from one that fires on every page load. Getting this right sets the expectation for your bounty range before the triage team even reads your steps.

Understanding writing effective bug reports for development teams helps here too. Clear reproduction steps, specific environment details, and visual evidence are universal across bug reporting contexts.

Why Reproduction Steps Matter More Than Technical Complexity

A sophisticated exploit that cannot be reproduced is worth nothing on a bounty platform. A simple IDOR with clear, numbered steps gets paid.

Triage teams reproduce your finding before escalating it. If they cannot follow your steps and see the vulnerability, your report goes into a “needs more information” state. Every round trip adds days to your payout timeline.

The Bug Bounty Report Template

Here is the bug report template we recommend for bounty submissions. It covers every field that triage teams expect to see.

Title Format

Use this structure: [Vulnerability Type] in [Component] allows [Impact]

Examples:

• “Stored XSS in profile bio field allows session hijacking”
• “IDOR in /api/v2/users/{id} allows access to any user’s PII”
• “Authentication bypass via password reset token reuse allows account takeover”

Your title should tell the full story in one line. Triage analysts use titles to prioritize their queue.

Avoid generic titles like “XSS found” or “Vulnerability in API.” These tell the triage team nothing about scope or severity, and they get deprioritized behind more descriptive submissions.

Copy-Paste Template

## Summary
[2-3 sentences. State the vulnerability, where it exists, and what
an attacker can do with it.]
 
## Severity
**CVSS Score:** [X.X] ([Critical/High/Medium/Low])
**Vector:** [CVSS vector string]
**Justification:** [1-2 sentences explaining the score]
 
## Steps to Reproduce
1. [Start from an unauthenticated or standard-user state]
2. [Navigate to / send request to...]
3. [Perform the action]
4. [Observe the result]
 
## Proof of Concept
[Screenshots, video recording, HTTP request/response pairs,
or code snippets that demonstrate the vulnerability]
 
### HTTP Request
[Paste the raw request]
 
### HTTP Response
[Paste the raw response showing the vulnerability]
 
## Impact
[What can an attacker do? Who is affected? How many users?
Be specific and quantify where possible.]
 
## Suggested Fix (Optional)
[Your recommendation for remediation. This is optional but
increases your credibility and may increase the bounty amount.]
 
## Environment
- **Target:** [URL or asset]
- **Account used:** [test account details if applicable]
- **Browser/Tool:** [e.g., Burp Suite 2024.1, Chrome 120]
- **Date tested:** [Date]

Every field serves a purpose. The title tells triagers what the bug is before they read anything else. The summary gives them the “so what.” The steps let them verify. The proof of concept shows it works. The impact statement connects the vulnerability to business risk.

Real Bug Bounty Report Examples

Templates are useful, but seeing real reports teaches you what actually works. Here are three anonymized bug report examples based on publicly disclosed submissions.

Example 1: XSS Report That Got Paid

Title: Stored XSS in comment field allows cookie theft for authenticated users

What it did right:

• Clear title with vulnerability type, location, and impact
• Reproduction steps started from a new user registration
• Included the exact payload that triggered the XSS
• Screenshot showed the alert box firing in the context of the target domain
• Impact section quantified the number of affected users (all authenticated users of the forum)

Payout: $750 on a medium-tier program

The key detail: the researcher included the HTTP response showing the unsanitized input reflected in the page source. This removed any ambiguity about whether the XSS was actually stored or just reflected.

The researcher also noted the WAF bypass technique used in the payload, which demonstrated technical depth and helped the security team understand the full attack surface.

Example 2: IDOR Report That Got Rejected, Then Rewritten and Paid

Original submission (rejected):

The API at /api/users/ lets you access other users’ data by changing the ID parameter. This is a serious vulnerability.

Why it was rejected: No proof of concept, no reproduction steps, no CVSS score, and no evidence of actual data exposure.

Rewritten submission (paid $1,200):

Title: IDOR in /api/v2/users/{id}/profile allows any authenticated user to read other users’ email, phone, and address

What changed:

• Specific endpoint with method (GET)
• Two HTTP request/response pairs showing data from two different user accounts accessed with one session token
• CVSS score of 6.5 (Medium) with justification
• Impact section listed the exact PII fields exposed

The format change took 20 minutes. The payout went from $0 to $1,200.

Example 3: Before and After Comparison

Before (no response for 14 days):

Found auth bypass. Can log in as admin. See attached screenshot.

After (triaged in 6 hours):

• Title: “Authentication bypass via manipulated JWT ‘role’ claim allows admin panel access”
• Steps showed the exact JWT modification using jwt.io
• Included three screenshots: the decoded token, the modified token, and the admin panel loaded with the modified token
• Impact section explained that admin access allows user data export, configuration changes, and API key rotation

The finding was the same. The difference was entirely in the bug report format. Structure and evidence turned an ignored submission into a fast triage.

Across all three examples, the pattern is consistent. Reports that get paid share three traits: a descriptive title, numbered reproduction steps starting from a clean state, and visual or HTTP proof that the exploit works. Reports that get ignored are missing at least two of those three.

Bug Bounty Report Format for Major Platforms

Each bounty platform has its own submission flow and severity taxonomy. The bug report format stays the same, but small adjustments help your report land better.

HackerOne

HackerOne uses a structured submission form with these key fields:

• Weakness: Select from CWE categories (e.g., CWE-79 for XSS)
• Severity: Mapped to CVSS. HackerOne auto-calculates from the vector string you provide
• Proof of concept: Supports file attachments, inline images, and markdown
• Impact: Free-text field. Be specific here

HackerOne’s reputation system rewards well-formatted reports. Higher reputation means your reports get triaged faster in the queue. Building reputation early by submitting well-structured reports on smaller programs gives you an advantage when you move to higher-paying targets.

Bugcrowd

Bugcrowd uses its own Vulnerability Rating Taxonomy (VRT) instead of raw CVSS. Review the Bugcrowd submission guide  before your first submission.

Key differences from HackerOne:

• Severity is mapped to VRT categories, not CVSS directly
• Bugcrowd programs often have more specific scope definitions
• The triage team may reclassify your severity based on VRT mapping

Platform-Agnostic Best Practices

Verify scope before every submission: Read the entire program policy before testing, even on programs you have submitted to before. Scope changes.

Search for duplicates: Search the platform for existing reports on the same vulnerability before submitting. Duplicates waste your time and the triager’s time.

Respond to triage questions within 24 hours: When a triage analyst asks for clarification, responding within 24 hours keeps your report in the active queue. Slow responses push your report down the priority list.

Keep your report updated: If the vulnerability changes or you find a stronger exploit chain after submitting, update the report. Triage teams appreciate researchers who stay engaged.

Common Mistakes That Get Reports Rejected

Even with a solid bug bounty report template, these mistakes cause rejections.

Submitting out-of-scope findings: Every program publishes its scope. Testing assets outside that scope, even if you find a real vulnerability, results in an immediate closure. Some programs will reduce your reputation score for out-of-scope submissions.

Missing proof of concept: “I believe this endpoint is vulnerable to SQL injection” without a single payload or response is a theoretical report. Triage teams need evidence, not hypotheses. At minimum, include one request/response pair that demonstrates the vulnerability.

Overstating severity without evidence: Labeling everything as “critical” without a matching CVSS justification trains triage teams to distrust your assessments. Score honestly, and explain your reasoning. A well-justified medium-severity report gets more respect than an unjustified critical.

Duplicate submissions: Before submitting, search the program’s disclosed reports and Hacktivity feed. If you are not sure whether a finding is a duplicate, mention it in your report: “I did not find a disclosed report for this issue as of [date].” This shows diligence and gives the triage team context.

What Comes Next

A well-structured bug bounty report template is the fastest path to consistent payouts. The researchers who earn the most do not necessarily find the hardest vulnerabilities. They write the clearest reports. Start with the template above, practice the format on your next submission, and watch your triage times drop. For teams running internal security testing, ShotMark captures the technical evidence (screenshots, console logs, network requests, and session context) that security reports need.