How to Write a Bug Bounty Report That Doesn't Get Rejected

Most bug bounty rejections are not about the vulnerability — they are about the report. Triage teams close submissions daily because the researcher could not prove impact, skipped reproduction steps, filed a duplicate, or tested something out of scope. A well-written report turns a valid finding into a paid bounty. A sloppy one turns the same finding into "Informative" or "Not Applicable."

This guide covers the report structure platforms like HackerOne and Bugcrowd expect, the four rejection reasons you can prevent with better writing, and how to use our bug bounty report template to stay consistent. For a deeper dive on duplicate and informative closures, read why bug bounty reports get marked duplicate or informative.

The bug bounty report structure that works

Every platform has slightly different fields, but accepted reports share the same skeleton:

1. Title — specific, not vague ("Stored XSS via profile bio field" not "XSS found")
2. Severity — your suggested CVSS or platform severity with brief justification
3. Summary — two to three sentences: what the bug is and why it matters
4. Steps to reproduce — numbered, starting from a clean state
5. Proof of concept — screenshots, video, HTTP logs, or code
6. Impact — concrete attacker outcome (account takeover, PII exposure, financial loss)
7. Affected URL / asset — exact endpoint in scope
8. Remediation suggestion — optional but appreciated

Write as if the triager has never seen the application. They may be reviewing dozens of reports today and yours needs to stand on its own without a follow-up call.

Rejection reason 1: Missing or incomplete reproduction

"Cannot reproduce" is the most frustrating closure because you know the bug is real. It happens when:

• Steps assume a specific account type or feature flag you never mentioned
• Requests omit required headers, cookies, or CSRF tokens
• Steps skip intermediate actions (login, navigation, form submission)
• Timestamps or session state make the PoC expire before triage runs it

Fix this by testing your own steps on a fresh browser session before submitting. Include full HTTP requests from Burp Suite where possible. Note prerequisites explicitly: "Requires a verified business account" or "Only reproducible on mobile Safari." If the bug is intermittent, explain the conditions and provide multiple screenshots showing successful reproduction.

Rejection reason 2: No demonstrated impact

Finding a theoretical vulnerability is not the same as demonstrating risk. Triage teams downgrade or close reports when impact is stated but not shown:

• Self-XSS without a convincing delivery chain
• Open redirect without showing phishing or token theft
• Missing security headers without a specific exploit scenario on that site
• Low-privilege IDOR that only exposes the researcher's own data

Always answer: "What can an attacker actually do?" If you claim account takeover, show the session hijack or password reset abuse. If you claim data exposure, show the sensitive fields returned. Use our CVSS calculator to score based on demonstrated impact, not theoretical maximums. For writing impact sections in longer engagements, the same principles apply to penetration testing reports.

Rejection reason 3: Duplicate submissions

You cannot control whether someone else found the bug first, but you can reduce duplicate risk:

• Search the program's disclosed reports and duplicates before filing
• Submit promptly after discovery — triage timestamps matter
• If you find multiple instances of the same root cause, file one report with all affected endpoints listed
• Do not file separate reports for the same SQLi pattern across ten URLs — consolidate

If your report is marked duplicate, ask which original report it duplicates and study that report's structure. Often the accepted version had clearer impact or better reproduction. Our guide on duplicate and informative closures covers how to respond professionally.

Rejection reason 4: Out of scope

Every program publishes scope rules. Common out-of-scope items include:

• Third-party services and dependencies not owned by the target
• Social engineering, physical attacks, and denial of service
• Findings on deprecated or staging environments unless explicitly listed
• Rate limiting, SPF/DMARC, and missing best-practice headers (program-dependent)
• Vulnerabilities requiring unlikely user interaction without a realistic attack chain

Read the policy before testing, not after finding something. Quote the in-scope asset in your report title and affected URL field. If you are unsure whether an edge case is in scope, ask the program via the platform's communication channel before submitting.

Writing tips that speed up triage

Use clear, neutral language. Avoid hype ("CRITICAL 0DAY!!!") and avoid underselling ("minor issue maybe"). State facts: what you did, what happened, what an attacker gains.

Minimize noise. Do not paste entire HTML pages or 200-line stack traces. Highlight the relevant lines. Redact your own session tokens but keep enough for reproduction.

Suggest severity honestly. Overstating severity erodes trust and leads to downgrades. Understating may get you paid less than you deserve. Use CVSS as a starting point and adjust with a one-sentence rationale.

Attach a screen recording for complex multi-step bugs. A two-minute video can replace ten pages of ambiguous text.

Use a template, customize every report

Templates save time without making reports feel generic. Our bug bounty report template gives you the section headings and prompts — you fill in the specifics for each finding. Pair it with PoCcraft to generate consistent impact and remediation language, then edit for the target application's context.

For vulnerabilities that map to standard categories, reference OWASP Top 10 classifications in your description. This helps triagers route the report to the right engineering team faster.

The bottom line

Bug bounty success is half discovery, half communication. Prevent the four big rejections — missing repro, no impact, duplicates, and out of scope — by writing structured reports with numbered steps, demonstrated attacker outcomes, and explicit scope references. Use a template, validate severity with a CVSS calculator, and generate polished sections with PoCcraft before you hit submit.