// Bug Bounty AI guide

Writing a clear vulnerability report

What makes a vulnerability report easy to triage and act on — a precise title, real impact, reproducible steps, and concrete remediation, written for the person who has to fix it.

A vulnerability is only as valuable as the report that describes it. Triagers read a lot of submissions; the ones that get resolved quickly are the ones that let a reader reproduce the issue and understand its impact without guesswork. A good report is a piece of technical writing, and it follows a predictable structure.

Title: specific, not dramatic

State the vulnerability class and where it is, in one line. "Reflected XSS in the search parameter on example.com/search" tells a triager more than "Critical security issue!!!" ever will.

Impact: what an attacker could actually do

Explain the realistic consequence in terms of confidentiality, integrity, or availability — not the theoretical worst case. Tie it to the specific application: what data or action does this expose?

Steps to reproduce: exact and ordered

  1. Start from a known state (which account, which page).
  2. List each request or action in order, with the exact input used.
  3. Describe the observed result and why it demonstrates the vulnerability.

Include the raw request/response where it helps. The test is simple: could someone unfamiliar with your finding reproduce it from your steps alone?

Remediation: point toward the fix

Suggest how to address the root cause — output encoding, parameterized queries, an authorization check. You do not have to design their fix, but naming the underlying weakness (its CWE) helps the team resolve it and catch siblings.

Related guides

A bug bounty reconnaissance workflowA practical, repeatable reconnaissance workflow for authorized bug bounty targets — from confirming scope to mapping the attack surface and deciding where to look first.Understanding bug bounty program scopeHow to read a bug bounty program's scope so you test the right assets — in-scope vs out-of-scope, accepted vulnerability types, and the rules that keep your testing authorized.

Terms used here

Responsible disclosureThe practice of reporting a discovered vulnerability privately to the affected organization and giving it reasonable time to fix the issue before any public discussion. Also called coordinated disclosure; it prioritizes protecting users over publicity.VulnerabilityA flaw or weakness in a system that could be exploited to compromise its confidentiality, integrity, or availability. Not every vulnerability is equally serious; severity depends on how easily it can be exploited and what the impact would be.RemediationThe action taken to resolve a vulnerability — such as applying a patch, changing a configuration, or adding a control. A good vulnerability report includes remediation guidance so the owner knows not just what is wrong but how to fix it.CWE (Common Weakness Enumeration)A community-maintained list of software and hardware weakness types — such as SQL injection or improper authentication. Where a CVE names one specific vulnerability, a CWE names the underlying category of weakness that caused it.