report-gen

name	report-gen
description	Bug bounty report generation — structure, triager-friendly writing, CVSS scoring, and chain reporting. Use when finalizing a finding for submission.

Report Generation

Audience

A triager will spend 2-5 minutes deciding whether your report is valid and what severity to pay. Optimize for that.

The template (non-negotiable)

# {Specific title: what + where + impact class}

**Severity:** {CVSS vector} — {score} ({Critical|High|Medium|Low})
**Target:** {hostname + endpoint or feature name}
**Weakness:** CWE-{id} {name}

## Summary
{One paragraph. Two sentences if you can. Assume the triager skims.}

## Steps to Reproduce
1. {Action}
2. {Action}
{Use exact HTTP requests in fenced code blocks. Redact only your session token.}

## Proof of Concept
{curl one-liner, or Burp request, or recording link.}

## Impact
{What an attacker gains, concretely. Quantify: "all N records", "any of M users".}

## Suggested Fix
{Root cause remediation, not symptom patch.}

## References
- CWE-{id}
- OWASP: {category}
- {related disclosed reports, if any}

Title craft

• Bad: "Security issue in API"
• Okay: "IDOR in invoice endpoint"
• Good: "IDOR on GET /api/v2/invoice/{id} allows any authenticated user to read any tenant's invoices"

Title = bug class + location + impact class.

Writing tone

• Plain English. No jargon the triager doesn't need.
• Show, don't claim. One raw request/response pair beats three paragraphs of explanation.
• No threats, no drama. Facts and reproducibility are what get paid.
• Redact your own tokens. Replace with {REDACTED_SESSION}.

CVSS 3.1 quick pointers

• Attack Vector: Network (N) for remote, Local (L) for local file
• Attack Complexity: Low (L) unless conditions rare
• Privileges Required: None (N), Low (L=regular user), High (H=admin)
• User Interaction: None (N), Required (R)
• Scope: Changed (C) if you cross a trust boundary (e.g. SSRF)
• C/I/A: None / Low / High — think per-record vs. system-wide

Use https://www.first.org/cvss/calculator/3.1 to double-check the vector.

Chains

If A + B = C (bigger than either alone):

• Submit one report titled for the chain's impact
• Describe both bugs inline, but make clear they compose
• Score CVSS for the chained impact
• Single reports for A and B only if the program explicitly wants separate submissions

Common reasons reports get marked informative

• Self-XSS (attacker attacks themselves)
• CSRF on non-state-changing endpoints
• Missing security headers without demonstrated impact
• Info disclosure of data already public
• Theoretical issues without PoC
• Duplicates — search the program's disclosed reports before submitting

Before you click submit

• Does the repro work from a fresh browser/curl session?
• Have I removed real user data from the PoC?
• Is the severity justified by the impact statement?
• Is the fix suggestion concrete?
• Is the target in scope per today's program page?