Writing the Report

> This page distills how the highest-value reports in this corpus were written and defended, based > on the disclosed timelines (the mediator/triage/reporter exchanges). The bug gets you in the door; > the writeup gets you paid. General craft is marked as background; specific timeline lessons are > cited to their report IDs on the class pages.

§Anatomy of a report that triages fast

Title — the actual impact, not the class. "Full account takeover of any user via password

reset host-header injection" beats "Host header injection".

Summary — one paragraph: who the attacker is (auth level), what they do, what they get. The

program's summary field in the best reports is a crisp root-cause statement — write theirs for them.

Steps to reproduce — numbered, copy-pasteable, with exact requests. Assume the triager pastes

them verbatim. Include prerequisites (two accounts, a collaborator domain, a specific plan tier).

PoC — a single curl/HTML file/video. Blind bugs: show the callback.
Impact — walk the impact ladder (see triage-and-impact.md). Quantify data exposure.
Remediation — a one-line correct fix signals you understand the root cause; it also speeds

the program to "resolved".

§What the timelines reward

Across the resolved reports, these behaviors correlate with fast triage and higher final severity:

Reproducibility over prose. The single biggest downgrade risk is "we couldn't reproduce."

Pin versions, environment, timing, and account state. For races, ship a video or a script.

Escalate on request, immediately. When triage asks "what's the real impact?", the reports that

jumped in severity answered with a working next-rung PoC within a reply, not an argument.

Honesty about limits. Overclaiming ("this is RCE") when it isn't gets you distrusted for the

rest of the thread. State exactly what you proved and what you believe is reachable next.

Minimal, respectful footprint. Don't dump databases; extract one row as proof. Don't pivot

into other users' data beyond what proves impact. The timelines show programs reacting badly to over-testing and well to surgical PoCs.

Answer precisely and fast. Terse, technical, on-point replies keep momentum; long delays and

vague answers stall reports into "informative".

§What the timelines punish

Missing steps / environment → "cannot reproduce" → closed.
Impact left as "could potentially" → downgraded to Low/Informative.
Reporting a primitive with no delivery (self-XSS, theoretical CSRF) → N/A.
Arguing severity instead of demonstrating it.
Re-reporting a known/duplicate issue without reading scope.

§Disclosure & learning

Request disclosure where allowed — disclosed reports (like this corpus) are how the field learns

and how you build reputation.

Keep your own notes: the failed bypasses in a timeline are as instructive as the working one.

When a program fixes your bug, the next variant is often still open (see the "Bypasses" and "Also seen in" sections on every class page).

§Template (fill in and adapt)

## Summary As a <attacker role>, I can <action> and obtain <impact> belonging to <victim>, because <root cause>. ## Steps to reproduce 1. ... 2. ... ``` <exact request> ``` 3. Observe <exact tell in response>. ## Proof of concept <single curl / HTML file / video link> ## Impact <walk the ladder to business impact; quantify> ## Remediation <the correct, root-cause fix in one or two lines>

§References

Cross-links: methodology/triage-and-impact.md, every class page's "Remediation" and

"Real-world case studies" sections (each grounded in a disclosed timeline).

Reference books: Bug Bounty Bootcamp (Writing Good Reports), Real-World Bug Hunting.