Safety Center
Vulnerability Report Template: Annotated Guide
A good vulnerability report is a professional document: it lets a stranger reproduce your finding, judge its impact, and fix it. This page gives you a full annotated template for lab and authorised-programme findings — and shows you what to leave out.
Try the tools: Bug Bounty Scope Checker · Vulnerability Report Builder
Why the report is the product
In security research, the report is what gets fixed, paid, or recognised — not the discovery alone. A researcher who finds a serious weakness and writes a confusing report will see it closed as uninformative; a researcher who finds a medium weakness and writes a clear, reproducible report will see it fixed and, in a bounty programme, rewarded. Report writing is the skill the field's practitioners call the most underestimated, and it is the skill this template teaches.
This template is for lab findings and findings made inside an authorised programme's scope, reported through the proper channel. It is not a vehicle for reporting unauthorised testing, and it contains no exploit code or payloads aimed at live targets.
The full annotated template
Copy the structure below and fill in each section. The annotations explain what belongs in each part and what does not.
1. Title
One line, specific and honest. Good: 'Stored cross-site scripting in the lab blog comment field (lab-demo-app v1.2)'. Bad: 'Critical security flaw!!!' or 'XSS found'. The title should let a triage analyst know the weakness class, the location, and the asset — without exaggeration. Never inflate severity in the title; the impact section is where severity is argued, with evidence.
2. Summary
Three to five sentences: what the weakness is, where it is, what an attacker could do with it, and what you recommend. Write this last, after the rest of the report, so it accurately reflects what you proved — not what you hoped to prove.
3. Affected asset
The exact asset: product and version, URL or host, and the environment (lab, authorised programme, date tested). Include the scope you relied on and the date you read it — for programme reports, this line shows you tested inside the rules. If the asset is a lab system, say so plainly.
4. Steps to reproduce
Numbered steps that a stranger can follow to see the same behaviour, starting from a clean state. Include the exact inputs, the exact navigation, and the expected result at each step. If a step requires an account, say which type (a test account you created in the lab, for example). Reproducibility is the test: if the reader cannot reproduce it from your steps alone, the report is incomplete.
5. Evidence
Screenshots, log excerpts, or response excerpts that show the weakness — with sensitive values redacted and fictional data used wherever possible. Annotate each piece of evidence in one sentence: what it shows and why it matters. Evidence without annotation is noise; a reader should never have to guess what a screenshot proves.
6. Impact — argued honestly
Explain what an attacker could actually do with this weakness, in concrete terms: read data they should not see, act as another user, change data, or take over an account. Be honest about the limits: if exploitation requires a specific condition, say so. A crash, by itself, is not a vulnerability — impact must be shown. If you are unsure about impact, say so and explain your reasoning; a triage team would rather see honest uncertainty than inflated claims.
7. Severity suggestion
Suggest a severity (low, medium, high, critical) with your reasoning, and a CVSS vector if you can construct one accurately. Make clear this is your suggestion: the programme or owner makes the final call. Do not present your suggestion as the official rating.
8. Suggested fix
One or two paragraphs on how to fix it: the concrete change (for example, 'validate and encode this field on output', 'enforce authorisation checks on this endpoint'), not a vague 'improve security'. If you know the standard fix for this weakness class, name it. You are helping the owner fix the issue, not just reporting it.
9. References
Links to the relevant standard or documentation — for example, the OWASP guidance for the weakness class, the CVE record if one exists, or the vendor advisory. References show your finding is grounded in established knowledge, and they help the owner verify the fix.
Worked example: a lab finding, written up
Asset: lab-demo-app v1.2, a fictional training application running in a local lab (clearly labelled, no real users, no real data). Title: 'Stored cross-site scripting in the lab blog comment field'. Summary: a comment submitted through the blog form is stored and then rendered in other users' browsers without encoding, so a script in a comment executes for anyone who views the post.
Steps to reproduce: 1. Log in to the lab app as test.user. 2. Open the blog post 'Welcome'. 3. Submit a comment containing a harmless script marker (a simple alert with the text 'lab-test'). 4. Log in as a second test user and open the same post. 5. Observe that the marker executes in the second user's browser. Evidence: two screenshots — the submitted comment and the marker executing for the second user — with fictional usernames throughout.
Impact: an attacker who can post a comment could run scripts in other users' browsers, potentially stealing session tokens or performing actions as those users. The impact is limited in this lab because there are no real users and no real data, and the report says so. Suggested fix: encode user-supplied content on output and apply the standard output-encoding guidance for this weakness class.
What to leave out
- Exploit code or payloads aimed at live targets — the minimum reproduction steps are enough.
- Real credentials, tokens, personal data, or customer logs.
- Anything obtained by testing a system without permission.
- Inflated severity claims, or impact you cannot demonstrate.
- Screenshots containing real names, real email addresses, or real internal hostnames — redact or replace with fictional values.
Before sending a report, do a final check: can a stranger reproduce this from my steps alone? Is every claim evidenced? Is the impact argued honestly? Have I stated the scope and the date? If the answer to all four is yes, send it — and then wait patiently for triage.
For the context this template fits into, read Security Research for Beginners, Bug Bounty for Beginners, and How to Read a Bug Bounty Scope Page.
Sources
- CERT Guide to Coordinated Vulnerability Disclosure
- OWASP — vulnerability reporting and testing guidance
- Research methodology — how this guide was researched
Frequently asked questions
What should a vulnerability report include?
A title, the affected asset and version, steps to reproduce, evidence, an honest impact assessment, a severity suggestion with reasoning, and a suggested fix. Every claim should be reproducible by the reader.
How long should a vulnerability report be?
As long as it needs to be to reproduce the finding — usually one to three pages. Short reports with clear steps beat long reports with vague ones.
Can I use this template for a real bug bounty report?
Yes — for findings made inside an authorised programme's scope, reported through the programme's official channel. Never use it to report a finding made by testing a system without permission.
Should I include exploit code in a report?
No. Include the minimum steps needed to reproduce the issue. Detailed exploit code, payloads aimed at live targets, and automation for attacking real systems do not belong in a report — or on this site.
What is coordinated disclosure?
Reporting a vulnerability privately to the owner first, giving them time to fix it (a window of around 90 days is commonly cited, though it varies), and only disclosing publicly afterwards, in line with the programme's or owner's policy.
What if my report is marked as a duplicate or not a vulnerability?
That is normal, especially for beginners. Read the triage feedback, check whether the finding was already known or whether the impact was not demonstrated, and learn from it. A rejected report that teaches you something is still useful.