Skip to main content

Bug Bounty Report

Writing a clear and complete report is just as important as finding the vulnerability. A good report helps security teams understand, validate, and fix the issue fast and it increases your chances of getting a reward.

Here’s a standard format you can use.

Report Format​

# Vulnerability Report: [Title]

## Overview
- Severity: [Critical/High/Medium/Low]
- CVSS Score: [Score]
- Affected Component: [Component]

## Description
[Detailed technical description]

## Steps to Reproduce
1. [Step 1]
2. [Step 2]
3. [Step n...]

## Impact
[Business and technical impact]

## Proof of Concept
[Screenshots, videos, code]

## Recommendations
[Detailed fix recommendations]

## References
[CVE, CWE, related resources]

# Vulnerability Report: [Title]​

Start with a clear, short title. Like: Stored XSS in User Profile Name Avoid vague names like “Bug found” or “XSS”.

## Overview​

Give a quick summary of the bug’s severity and where it was found.

  • Severity: Use standard levels — Critical, High, Medium, Low.
  • CVSS Score: (Optional but helpful) Estimate the score using CVSS Calculator.
  • Affected Component: Be specific — e.g., user-profile endpoint, login form.
info

Keep this part short but clear. It’s the triager’s first glance.

## Description​

Write a technical explanation of the bug. Explain what the issue is, why it’s a problem, and how it works.

Recommended:

  • Mention the type of bug (XSS, IDOR, SSRF, etc.)
  • Describe the logic flaw or misconfiguration
  • Explain any conditions needed to trigger it
info

Write for both technical readers and less technical triagers. Avoid slang or overly complex terms.

## Steps to Reproduce​

List the steps in a clear, numbered format. This is crucial.

  1. Go to [URL or page]
  2. Login as [role, if needed]
  3. Enter [payload/data]
  4. Click [button/action]
  5. Observe [the bug]
info
  • Include request/response samples
  • Mention tools used (e.g., Burp Suite, browser console)
  • Keep steps minimal but complete

## Impact​

Explain the business and technical risk.

  • Can data be stolen?
  • Can accounts be hijacked?
  • Can users be tricked?
success

Example: “An attacker could inject a stored XSS that executes every time an admin opens the user profile, potentially stealing their session token.”

info

Try to link the bug to real-world damage. This helps justify severity.

## Proof of Concept (PoC)​

Show the bug in action. Use screenshots, curl requests, code snippets, or better — a short video.

info
  • Use clean, labeled screenshots
  • Highlight the bug clearly
  • Host your PoC video on an unlisted YouTube link or file share
  • Add JavaScript payloads or scripts used

In short make it easy for the triager to reproduce the bug fast.

## Recommendations​

Suggest how to fix the issue. You don’t need to write full code — just give the idea.

Examples:

  • Sanitize user input before rendering HTML
  • Add authorization checks to the endpoint
  • Use parameterized queries to prevent SQL injection
info

Keep it simple. You’re helping them fix it quickly.

## References​

Link useful resources:

  • CVEs, CWEs
  • OWASP pages
  • Articles or videos
  • Docs or RFCs related to the bug

Example:

Tips​

  • Use proper grammar and clear formatting (Markdown is best)
  • Be polite and professional — it helps a lot
  • Always test and verify the bug before reporting
  • Don’t include unnecessary info or filler

Remember: a clear report = faster triage = better chance of reward.