You found a real bug. Now comes the step that decides whether you get paid quickly, get paid slowly, or get closed as “informative”: the report. Triagers read hundreds of submissions. The ones that get accepted fast are the ones that make the vulnerability impossible to misunderstand and trivial to reproduce. Here’s how to write a report that respects the triager’s time — and gets your finding through.
Why the report matters as much as the bug
A triager can’t pay for a vulnerability they can’t reproduce or don’t understand. Two hunters can find the identical bug; the one whose report is clear, self-contained, and impact-focused gets triaged in minutes, while the vague one bounces back and forth for a week or gets closed. Your report is the product you’re actually delivering.
The anatomy of a great report
1. Title — specific, not clickbait
The title should state the vulnerability, the location, and the impact in one line.
- ❌ “Critical security issue!!!”
- ✅ “IDOR in /api/invoices/{id} allows any authenticated user to read other users’ invoices”
A triager should know exactly what they’re looking at before they open the report.
2. Summary — three sentences, up top
Open with a short paragraph: what the bug is, where it is, and what an attacker can do with it. Don’t make the reader dig for the point. If they read only this and your title, they should already grasp the severity.
3. Steps to reproduce — numbered, exact, copy-pasteable
This is the heart of the report. Number every step. Include the exact request (full URL, method, headers, body) and the exact response that proves the bug. Assume the reader will follow your steps literally, on a clean session, with nothing memorized from your head.
1. Log in as Account A (attacker), grab the session token.
2. Send: GET /api/invoices/1041 with Account A's token
3. Observe: 200 OK returning invoice #1041, which belongs to Account B.
(Full request/response below.)If setup is needed — two accounts, a specific role, a particular value — spell it out. A report that “works on my machine” but not the triager’s is a rejected report.
4. Proof — request/response or a short video
Paste the raw HTTP request and the relevant response, redacting only genuinely sensitive real data. For multi-step or client-side bugs (XSS, CSRF, OAuth flows), a short screen recording — under two minutes, no narration needed — often communicates in seconds what paragraphs can’t.
5. Impact — the part that sets the bounty
Spell out what an attacker actually achieves, concretely. Not “this is dangerous,” but: “An unauthenticated attacker can enumerate sequential invoice IDs to download every customer’s billing records, including names, addresses, and partial card data.” Tie it to who is affected and what data or action is exposed, and note the scale. This is what the reward is calculated against — don’t leave it to the triager to infer.
6. Remediation — brief and helpful
One or two sentences suggesting the fix (“enforce an ownership check on the invoice object against the authenticated user’s ID”) shows you understand the root cause and makes the program’s job easier. Keep it short; you’re pointing, not lecturing.
Calibrate the severity honestly
Don’t inflate. Claiming “Critical” on a self-XSS or a missing security header burns your credibility with that triager for every future report. Use the program’s severity framework (usually CVSS), pick the rating your proof supports, and let the impact section make the case. A well-argued High beats an over-claimed Critical that gets downgraded.
Before you hit submit — the checklist
- Is the vulnerable asset actually in scope? Re-read the scope. Out-of-scope reports get closed no matter how good the bug.
- Did you search for duplicates? Check the program’s disclosed reports and hacktivity. A duplicate is a real bug someone filed first — not a failure, but not a payout either.
- Can a stranger reproduce it from your steps alone, with nothing in their head?
- Did you avoid touching real users’ data, and say so?
- Is the impact stated in one concrete sentence?
The bottom line
A great report has a specific title, a three-sentence summary, numbered copy-pasteable steps, hard proof, and a concrete impact statement — in that order. Make the vulnerability impossible to misunderstand and trivial to reproduce, and you remove every reason for a triager to say no. The bug earns the bounty; the report is what gets it there.
Always test within an authorized scope and follow each program’s disclosure rules. Clear, honest reporting is what keeps the relationship between hunters and programs healthy.