/report

---

description: Write a submission-ready bug bounty report. Generates H1/Bugcrowd/Intigriti/Immunefi format with CVSS 3.1 score, proof of concept, impact statement, and remediation. Run /validate first. Usage: /report

/report

Generate a submission-ready bug bounty report.

Pre-Conditions

Run `/validate` first. All 4 gates must pass before running this command.

Never write a report before validating. N/A submissions hurt your validity ratio.

Usage

/report

Provide when prompted:

• Platform (HackerOne / Bugcrowd / Intigriti / Immunefi)
• Bug class
• Affected endpoint
• Your two test accounts and their IDs
• The exact HTTP request that demonstrates the bug
• The exact response that shows the impact
• Tech stack (for CVSS and remediation advice)

What This Generates

1. Title following the formula: [Bug Class] in [Endpoint] allows [actor] to [impact]
2. Summary paragraph (impact-first, no "could potentially")
3. Vulnerability details with CVSS 3.1 score and vector string
4. Steps to Reproduce with copy-paste HTTP requests
5. Impact statement with quantification
6. Recommended fix (1-2 sentences, specific)
7. Supporting materials section

Platform Selection

HackerOne Format

• Markdown sections: Summary, Vulnerability Details, Steps to Reproduce, Impact, Recommended Fix
• Include CVSS 3.1 score + vector string
• Include two test account setup instructions
• Keep under 600 words

Bugcrowd Format

• Title with VRT category: [VRT Category] > [Subcategory] > P[1-4]
• Expected vs Actual Behavior section
• Severity Justification section referencing Bugcrowd VRT

Intigriti Format

• CVSS score prominent at top
• Clear reproduction steps
• Business impact focused

Immunefi Format (Web3)

• Root cause in Solidity code
• Foundry PoC test included
• Economic impact quantified in $ value
• Comparison evidence (same check present elsewhere, missing here)

Writing Rules

1. Never use: "could potentially", "may allow", "might be possible"
2. Always prove: show actual data/action, not just "200 OK"
3. Impact first: sentence 1 = what attacker gets, not what the bug is
4. Quantify: how many users affected, what data type, $ amount
5. Short: triagers skim. < 600 words.
6. Human: write to a person, not a system

CVSS 3.1 Calculation Guide

Common patterns:

IDOR read PII (any user, auth needed):
→ AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 Medium

Auth bypass → admin (no auth):
→ AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical

SSRF → cloud metadata:
→ AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N = 9.1 Critical

Stored XSS (any user, scope changed):
→ AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N = 8.2 High

Escalation Language

Use when payout is being downgraded:

"This requires only a free account — no special privileges."
"The exposed data includes [PII type], subject to GDPR/CCPA requirements."
"An attacker can automate this — all [N] records in [X] minutes with a simple loop."
"This is expl