Free Tool
Vulnerability Report Builder
Finding a vulnerability is only half the job — the other half is writing it up so someone can reproduce it, understand its impact and fix it. This builder turns your notes into a structured report in the format security teams expect, ready to download and submit. It is for authorised and lab findings only.
Authorised and lab findings only. Use this builder for findings from systems you own, labs built for learning, or programmes whose scope explicitly permits your testing. Never use it to report something you found by testing a system without permission.
What this tool does
A good vulnerability report answers five questions in order: what is the problem, where is it, how do you reproduce it, what harm could it do, and what should be fixed. Security teams triage hundreds of reports, and the ones that get fixed first are the ones that make those answers easy to find. A report that buries the reproduction steps in a paragraph of background, or that claims a critical impact without showing how it was reached, wastes the triager's time and delays the fix.
This builder walks you through the standard structure. You fill in the title, the target, the severity you believe applies, a plain-English summary, the exact reproduction steps, the impact, and a suggested fix. The builder then assembles the report in a clean, copyable format and offers it as a downloadable text file, so you can attach it to a disclosure submission or keep it in your portfolio. A worked example is built in, so you can see what a complete report looks like before you write your own.
The builder also teaches the discipline that matters most in reporting: evidence over adjectives. A report that says a flaw is critical because it feels serious is worth less than one that shows the exact request, the exact response and the exact harm. The guide linked below contains a full annotated template with the same structure, explaining why each section exists and what triagers look for in it.
Try it
Fill in the fields for a finding from a lab or an authorised test. Everything stays in your browser until you download the report.
Waiting. Fill in the fields and press Build my report. The report is assembled in your browser; nothing is submitted anywhere.
How it works
The builder follows the structure that responsible disclosure programmes expect. The title names the flaw and the place in one line, so a triager can sort it without opening it. The target names the exact system and version, because a report without a target cannot be reproduced. The severity is your judgement, stated plainly — and the builder asks you to justify it in the impact section, because a severity without evidence is just an opinion.
The reproduction steps are the heart of the report. They must start from a clean state, list every click and input exactly, and end with the observed result — what you saw that proves the flaw exists. A triager who cannot reproduce a finding in a few minutes will usually ask for more information or close the report, so this section decides whether your report gets fixed or forgotten. Screenshots and short request logs help, but the steps themselves must be complete without them.
The impact section translates the technical finding into harm: what an attacker could actually do, and to whom. The fix section then suggests the standard remediation, stated as a direction rather than a demand — you are informing the team, not ordering it. The downloaded file keeps this structure, with headings and sections, so it can be pasted into a programme's submission form or attached as a text file.
Limitations
This builder writes a report; it does not judge whether your finding is real, nor whether your severity is right. A well-formatted report about a non-issue is still a non-issue, and a severity of critical needs evidence in the impact section to be believed. The builder also cannot check that your testing was authorised — that is your responsibility, and the banner at the top of this page states it plainly.
- The builder works on text you type. It does not attach screenshots, request logs or proof-of-concept files — add those to your submission separately, and never include exploit code or payloads that could be reused against a live system.
- Disclosure timelines vary by programme. The commonly cited window is around 90 days, but the programme's own policy is what counts — read it before you submit.
- Never publish a report publicly before the flaw is fixed and the programme allows it.
Examples
Example 1 — the worked example. Press Load the worked example to see a complete lab report: a stored scripting flaw in a lab shop's review form, rated high, with exact reproduction steps, a concrete impact (session theft from shoppers) and a standard fix. It is the model to copy: short, exact, evidence-first.
Example 2 — a weak report, improved. A first draft says: There is a security issue on the website, it seems serious, please fix it. The builder's structure forces the improvement: the title names the flaw, the steps show how to trigger it, and the impact explains the harm. The difference between the two drafts is the difference between a report that gets fixed and one that gets closed as unclear.
Example 3 — a severity that needs evidence. A researcher rates a finding critical because it involves an admin page. The builder's impact field asks what an attacker could actually do — and if the answer is that the page is already behind a login and shows no sensitive data, the honest severity is lower. The report format keeps the severity honest by tying it to the evidence.
Frequently asked questions
What makes a vulnerability report good?
Exact reproduction steps, a clear statement of impact with evidence, and a suggested fix — in that order. Triagers fix reports they can reproduce in minutes; vague reports get closed or ignored.
How do I choose a severity?
Judge by the real impact: what an attacker could do, to whom, and how easily. A flaw that needs a victim to click is less severe than one that works on its own. Show the evidence in the impact section so the triager can agree or disagree with reasons.
Should I include proof-of-concept code?
Only steps and observations that prove the flaw, never a reusable exploit. Describe what you sent and what happened; do not publish payloads that could be used against a live system.
How long should I wait for a fix before disclosing publicly?
Follow the programme's own policy. The commonly cited window is around 90 days, but it varies — the programme's policy is the rule, and you must never disclose before a fix without its permission.
Can I use this builder for a real bug bounty report?
Yes, for findings from authorised testing — labs, or programmes whose scope permitted your testing. Fill in the report, download it, and submit it through the programme's official channel.