How to write a bug bounty report that gets accepted — structure and common mistakes

[Vulnerability] in [Endpoint] leads to [Impact]

## Summary
[2 lines — what you found and what the business impact is]

## Severity
[Your proposed severity + CVSS 3.1 with justification]

## Impact
[What the attacker can do. Business language, not technical.]

## Steps to reproduce
1. ...
2. ...
3. ...

## Proof of Concept
[Video + reproducible curl + screenshots]

## Suggested remediation
[Concrete fix. If you know the stack, even better.]

## References
[Links to docs, similar CVEs, blog posts]

1. Create two accounts: victim (id=1001) and attacker (id=2042).
2. Log in as attacker. Get the JWT from the response (cookie `auth_token`).
3. Make the following request with the attacker's JWT but the victim's id:

```bash
curl -X GET 'https://target.com/api/v1/users/1001/exports' \
  -H 'Authorization: Bearer <attacker_JWT>' \
  -H 'Accept: application/json'

### PoC video — the multiplier

The PoC video is what separates €500 from €2500 on the same bug. Triage approves it 3× faster.

**Video template (60-90 seconds):**

> [!success] PoC video tools
> Loom (web), OBS Studio (desktop), QuickTime (Mac). No audio narration — triage prefers a silent video with text annotations. Upload to YouTube unlisted or to the program's service if offered (H1 Attachments, Bugcrowd Files).

---

## CVSS 3.1 — the 4 vectors that matter

You don't need to memorize CVSS, but understanding these 4 moves the severity 2 points:

| Vector | Raises score | Lowers score |
|---|---|---|
| `AV` (Attack Vector) | Network (N) | Local (L) |
| `AC` (Attack Complexity) | Low (L) | High (H) |
| `PR` (Privileges Required) | None (N) | High (H) |
| `UI` (User Interaction) | None (N) | Required (R) |

**Rules that apply 90% of the time:**
- Bug reachable via HTTP → `AV:N`.
- No weird pre-conditions → `AC:L`.
- Works without login → `PR:N` (Critical likely).
- Works with a victim click → `UI:R` (Medium likely).

Example: an auth-required stored XSS that needs the victim to open a page → `AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N` = 8.3 (High).

---

## The 10 mistakes that get reports rejected

| # | Mistake | How to avoid it |
|---|---|---|
| 1 | Not searching for dupes before submitting | Search disclosed reports + Hacktivity with the bug's keywords |
| 2 | Inflated severity (CVSS 9.0 for an info leak) | Be conservative. Triage rewards honesty. |
| 3 | Vague PoC ("try this and you'll see") | Full curl + video + numbered steps |
| 4 | Not testing your own repro before submitting | Log out, open incognito, repeat your steps. |
| 5 | Reporting out-of-scope issues | Read the **full** scope before starting |
| 6 | No impact statement | Always include "what the attacker can do in business terms" |
| 7 | Reporting trivial config issues (HTTP headers, banner version) | Only if there's a chain with real impact |
| 8 | Multiple bugs in one report | One report = one vuln. Separate reports get paid separately. |
| 9 | Aggressive tone in comments | "This is Critical, I don't get how you can't see it" → guaranteed N/A |
| 10 | Not replying to triage within 7 days | Reports in queue get closed without payout |

> [!warning] Anti-dupe checklist
> Before submitting: search the platform with 3 different keywords from the bug (endpoint, vuln type, payload). If you find even a similar one, read it thoroughly. Better to spend 30 more minutes analyzing than to eat a dupe.

---

## Templates for the most common reports

### Reflected XSS

```markdown
## Summary
The `q` parameter in `/search` reflects the user's input into the HTML context without sanitizing it, allowing arbitrary JavaScript execution.

## Steps to reproduce
1. Visit: https://target.com/search?q=<script>alert(document.domain)</script>
2. Observe the alert with the domain → XSS confirmed.

## Impact
An attacker can craft a malicious URL and send it to authenticated users. On click, the script executes in the victim domain's context → cookie theft (HttpOnly not verified), actions on behalf of the user, defacement.

## PoC
[video stealing a cookie and exfiltrating to the collaborator]

## Summary
The `/api/users/{id}/data` endpoint doesn't validate ownership between the `id` in the path and the request JWT. Any authenticated user reads other users' private data.

## Steps to reproduce
1. Create 2 accounts: A (id=1001), B (id=1002).
2. Log in as A. Capture the JWT.
3. Request: GET /api/users/1002/data with A's JWT → 200 OK with B's data.

## Impact
Full enumeration of the PII of the platform's N users (sequential id). GDPR violation.

## Summary
The `category` parameter in `/products/list` is vulnerable to error-based SQLi. The payload `' OR 1=1--` triggers a MySQL error leaking the query structure.

## Steps to reproduce
1. GET /products/list?category=' OR 1=1-- → 500 with MySQL error
2. Confirm via sqlmap: `sqlmap -u "https://target/products/list?category=1" --dbs`
3. Output: 12 databases, including `users_prod`.

## Impact
Full read of the `users_prod` DB (including password hashes, emails, payment refs). Possible RCE via `INTO OUTFILE` if the MySQL user has the FILE privilege.