Bug Bounty Reporting Guide

A practical reference for writing and submitting your first vulnerability report.

What is a bug bounty?

A bug bounty is a reward offered by an organization for finding and reporting security vulnerabilities in their systems. Programs define what you can test, how to report, and what you get in return - sometimes money, sometimes just recognition. A Vulnerability Disclosure Program (VDP) is similar but typically does not offer monetary rewards. Both exist to give researchers a safe, authorized way to report issues.

Before you start

Read the program rules

Every program has a policy page. Read it completely before doing anything. It tells you what is allowed, what is off-limits, and how they want to receive reports.

Understand scope

Scope defines which assets you are authorized to test - specific domains, apps, APIs, or IP ranges. Testing anything outside scope can get your report rejected or, worse, get you into legal trouble. When in doubt, ask the program before testing.

Check safe harbor and legal terms

Safe harbor clauses protect you from legal action when you follow the rules. Not all programs offer this. If a program has no safe harbor language, proceed with extra caution. Some programs reference specific legal frameworks - understand what they cover.

Finding vulnerabilities

Learning to find bugs takes practice. These resources cover the fundamentals of web security testing, from injection flaws to authentication bypasses.

PortSwigger Web Security Academy Interactive labs and learning paths OWASP Top 10 2025 The most critical web app security risks Hacker101 Free training with CTF challenges from HackerOne Bugcrowd University Bug hunting methodology modules OWASP WebGoat Deliberately vulnerable app for practice TryHackMe Gamified rooms and learning paths PentesterLab Hands-on web security exercises HackTheBox Academy Structured offensive security courses

Writing the report

What to include

Title - a clear, specific summary of the vulnerability
Description - what the vulnerability is and where it exists
Steps to reproduce - exact steps anyone can follow to trigger the bug
Impact - what an attacker could do with this vulnerability
Severity - your assessment using CVSS or the program's rating system
Proof of Concept - screenshots, videos, HTTP requests, or scripts
Environment - browser, OS, tools, and any specific configuration used

Report template

## Title
[Type of vulnerability] in [affected component]

## Description
[What the vulnerability is and why it matters]

## Steps to Reproduce
1. Go to [URL]
2. [Action]
3. [Action]
4. Observe [result]

## Impact
[What an attacker could achieve - data access, privilege escalation, etc.]

## Severity
[Critical / High / Medium / Low] - CVSS: [score]

## Proof of Concept
[Screenshots, code snippets, HTTP requests]

## Environment
- Browser: [e.g. Chrome 120]
- OS: [e.g. Ubuntu 24.04]
- Tools: [e.g. Burp Suite Community]

Common mistakes

Writing vague descriptions without technical detail
Missing or incomplete reproduction steps
Inflating severity to try to get a higher payout
Reporting issues that are out of scope for the program
Not checking for duplicates before submitting
Using threatening or aggressive language

Submitting your report

Finding the right channel

Check for a security.txt file at /.well-known/security.txt on the target domain. Many companies use platforms like HackerOne, Bugcrowd, or Intigriti - submit through the platform if one exists. If neither is available, look for a security contact email (often [email protected]).

After you submit

Acknowledgment - the program confirms they received your report
Triage - a triager validates the vulnerability and assesses severity
Clarification - you may be asked for more details or to verify a fix
Fix - the vendor patches the vulnerability
Disclosure - the report may be published, depending on the program's policy

Handling responses

Silence - wait at least 2 weeks before following up. Platforms usually have SLA timers.
Rejection - ask for a clear reason. If you disagree, provide additional evidence calmly.
Lowballed severity - respond with a clear explanation of impact, referencing CVSS if possible.
Clarification requests - respond promptly with the details asked for. This speeds up resolution.

Disclosure timeline

The industry standard is 90 days - after reporting, the vendor gets 90 days to fix the issue before the researcher may disclose it publicly. This is sometimes called "coordinated disclosure."

Some programs have their own timelines. Always check the program's disclosure policy first. If you want to publish a writeup after a fix, confirm with the program that they are comfortable with it.

If a vendor is unresponsive after repeated follow-ups, you may consider escalating through a CERT (like CERT/CC) or disclosing through a CNA. Full unilateral disclosure should be a last resort.

Staying legal

Only test systems and assets that are explicitly in scope
Understand the laws in your jurisdiction - the CFAA (US) and Computer Misuse Act (UK) are strict
Do not access, copy, or store user data beyond what is needed to prove the vulnerability
Never use a vulnerability for personal gain beyond the bounty reward
Check if your employer's contracts restrict security research
Do not threaten to disclose publicly as leverage for a payout - this can be treated as extortion
Keep records of everything you do during testing

This is general guidance, not legal advice. Consult a lawyer if you have concerns about a specific situation.

Glossary

Bug Bounty: A program where organizations pay researchers for finding and reporting security vulnerabilities.
VDP: Vulnerability Disclosure Program. Like a bug bounty but without monetary rewards - a channel for reporting issues responsibly.
CVE: Common Vulnerabilities and Exposures. A unique identifier (e.g. CVE-2024-1234) assigned to a publicly known vulnerability.
CVSS: Common Vulnerability Scoring System. A standard for rating vulnerability severity on a 0-10 scale.
CWE: Common Weakness Enumeration. A categorized list of software and hardware weakness types.
Safe Harbor: A legal agreement that protects researchers from prosecution when they follow the program's rules.
Scope: The set of assets (domains, apps, APIs) that a program authorizes you to test.
Triager: A person who reviews incoming vulnerability reports, validates them, and assigns severity.
PoC: Proof of Concept. A demonstration that proves a vulnerability exists and can be exploited.
Coordinated Disclosure: A process where the researcher and vendor agree on a timeline before the vulnerability is made public.
security.txt: A standard file (/.well-known/security.txt) that tells researchers how to report vulnerabilities to a site.
CFAA: Computer Fraud and Abuse Act. US federal law governing unauthorized computer access - relevant to legal boundaries.
Zero-day: A vulnerability that is unknown to the vendor and has no available patch.
Severity: The rated impact of a vulnerability, typically Critical, High, Medium, Low, or Informational.
Duplicate: A report for a vulnerability that has already been reported by another researcher.
CNA: CVE Numbering Authority. An organization authorized to assign CVE identifiers to vulnerabilities.