Triage & Demonstrating Impact

> A bug is worth what you can prove it does. The gap between an "informative" and a $20k report in > this corpus is almost never a different bug — it's a better-demonstrated impact. This page is the > reusable playbook for turning a finding into an accepted, well-paid report.

§The impact ladder

For every finding, ask "so what?" until you hit business impact:

reflected input → XSS fires → steal session cookie → account takeover → access all users' data open redirect → chains to OAuth code theft → account takeover SSRF → reach 169.254.169.254 → cloud creds → read prod data / RCE IDOR on /invoice/<id> → read one → enumerate all → mass PII disclosure CSRF on email-change → attacker sets victim email → password reset → ATO

The reporters who get paid walk the ladder in the PoC, they don't leave it as "could lead to".

§Severity: speak CVSS but lead with the story

Map to CVSS for the number, but the narrative wins triage: "As an unauthenticated attacker I did

X and obtained Y belonging to another user." Concrete, reproducible, other-user impact.

Cross-tenant / cross-user impact almost always bumps severity. Show it with two accounts

(attacker + victim) so triage can't dismiss it as self-only.

Sensitive-data reports: quantify. "Any user's full name, email, and phone via /api/users/<id>"

with a redacted sample beats "PII leak".

§Build a PoC triage can run in 60 seconds

Minimal, self-contained: one curl, or a single HTML file for CSRF/XSS/clickjacking.
Use placeholders (TARGET, VICTIM_ID, COLLAB) and mark exactly what to substitute.
Include the full request and response (headers + relevant body), not a screenshot only.
For blind bugs (blind SSRF/XSS/SQLi/OOB), use a collaborator/canary and show the callback.
Redact real secrets in your writeup (the disclosed reports here use █ for exactly this reason) —

but prove you had them.

§Avoid the "useless report" traps (why reports get closed)

These are the recurring reasons reports in this corpus were marked informative/N-A — don't ship them:

No impact. Missing security header, verbose banner, version disclosure, TRACE enabled — with

no demonstrated exploit. Turn it into impact or don't report it.

Self-XSS / self-anything. Needs a delivery vector to matter. Find the stored/reflected path.
Rate-limit only. Report it with a consequence (OTP brute, enumeration, cost amplification).
Theoretical / best-practice. "Cookie missing HttpOnly" is only a finding if you show the XSS

that reads it.

Clickjacking on a page with no state-changing action. Frame something that does something.
Out-of-scope / duplicate. Read scope and known-issues first.

§Timeline craft (from the disclosed exchanges)

The disclosed timelines in this corpus repeatedly show what moves a report forward:

Reproduce it for them. Programs downgrade what they can't reproduce. Exact steps, exact

versions, a video for timing/race bugs.

Escalate proactively but honestly. Offer the next rung ("I can also do Z, want a PoC?") without

overclaiming. Overstated impact gets you distrusted and downgraded.

Answer questions fast and precisely. Fast, technical replies correlate with higher final

severity across the resolved reports.

When pushed back, provide the missing rung, not an argument. A working escalation PoC ends most

"informative" disputes.

§References

Cross-links: methodology/reporting.md, chains/README.md, every vulnerabilities/* page's

"Escalation & chaining" and "Real-world case studies" sections.

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