Bug Bounty: How to Write a Vulnerability Report

Sep 11

2 min read

Triage doesn't want a thriller. They want title, impact, steps, evidence, and remediation in that order—fast.

Think of your reader as a tired developer between meetings. Respect their time and they'll respect your severity.

Great reports read like instructions for a busy engineer—assume they have twenty minutes and no context about your two-week rabbit hole.

Title and summary

Lead with what crosses a boundary: 'Staff API returns other users' billing addresses.' Avoid jargon stacks in the title.

Two sentences on business impact: confidentiality, integrity, availability, or fraud—pick the real one.

Numbered steps with exact URLs, roles, and request IDs if available. One curl or Burp export beats prose novels.

Suggest server-side checks, not 'use a WAF.' Link CWE or OWASP API entries when helpful—not as padding.

A clean report gets paid and cited; a messy one gets closed as informative.

Only include data you're authorized to access—mask real user records.

Read your report aloud once—awkward phrasing jumps out when spoken that eyes skip on screen.

Small habits compound—what feels like overhead early becomes speed when deadlines hit.

If impact feels fuzzy, rewrite the title until it isn't.

Pick a CVSS vector you can defend in one paragraph—if you need creative justification, severity might be wrong.

Offer a retest window and note fixed versions when retesting—programs remember helpers.

Compress videos; triage opens tickets on phones. Highlight clicks with cursor visibility.

List prerequisites clearly: two accounts, specific plan tier, beta flag enabled.

Offer remediation validation for free on criticals when time allows—it speeds bounty payment.

Bug Bounty: A Practical Note-Taking Template

Bug Bounty: Handling Triage and Pushback Professionally

Information Disclosure: The Quiet Vulnerability Class