report-writing

Structure the report as Summary, Vulnerability Details, Steps to Reproduce, Impact, and Recommended Fix. Lead with the exact impact in the first sentence, include copy-paste-ready HTTP requests, and attach a screenshot showing the attacker's session receiving victim data.

Use the formula: [Bug Class] in [Exact Endpoint] allows [attacker role] to [impact] [victim scope]. For example, "IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data" instead of vague titles like "IDOR vulnerability found".

Bugcrowd maps findings to its Vulnerability Rating Taxonomy with default priorities, while CVSS computes a numeric score from exploitability metrics. They disagree roughly 30% of the time, so file a severity-request paragraph citing the CVSS vector and the matching VRT entry when the default rates lower.

A typical IDOR reading other users' PII scores 6.5 Medium with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Raise severity if the IDOR allows writes or deletes, affects all users, or requires no victim interaction.

Reports get N/A when they claim theoretical impact using phrases like "could potentially" without demonstrating the attack end-to-end. Either show the full exploit chain with request and response evidence, or downgrade the severity claim to match what was actually proven.

Use the red team template when the engagement is an external red team assessment rather than a bug bounty program. Red team reports use a different structure (Subject, Observations, Description, Impact, Recommendation, PoC) aimed at client stakeholders instead of platform triagers.