A good vulnerability report lets a stranger reproduce the problem in minutes. Include reproduction steps, the raw requests and responses, any proof-of-concept code, a plain statement of impact, and your intended disclosure timeline. Write for a reader who may not be a security specialist.
Lead with the impact in one sentence
The first line should say what an attacker can do. "An unauthenticated user can read another customer's invoices by changing the invoice ID" tells a triager more than a long preamble about the class of bug. Put the severity discussion after the facts, not before.
The OWASP cheat sheet makes the same point: use plain language, because the person who receives the report may be a support agent or a developer, not a security engineer.
Make it reproducible
List the steps numbered, starting from a clean state. Name the account type you used, the URL, the exact parameter and the value you changed. Then attach the evidence the cheat sheet asks for:
- HTTP requests and responses
- Screenshots
- Proof-of-concept code, if you have it
- The impact in your own words
Say what you expected and what happened instead. If the issue depends on a browser version, a feature flag or a timing window, say so. A report that works only on your machine will sit in a queue.
Keep the evidence clean
Respect privacy. Redact personal data from screenshots and logs, and stop as soon as you have shown the issue exists. You do not need to download a table of real customer records to prove that you can. Test only against accounts you own and only within the scope and rules the organization has published.
Suggest, but do not insist
General fix guidance is welcome. A confident, specific recommendation is welcome too, but only if you are sure of it. Defenders know their code and deployment better than you do, and an overconfident fix suggestion can derail a conversation.
State your timeline politely
If you plan to publish after a period, say so in the first message, in a calm tone. This is not a threat. It tells the team what clock they are on. If you are reporting through a bounty program, check its terms first, because many programs restrict publication. For common timelines, see disclosure deadlines explained.
What to leave out
Do not demand payment before revealing details, and outside a bounty program avoid raising rewards in your first message. Do not post details on social media while you are looking for the right contact. If you cannot find any contact, a national or sector CERT is a reasonable route. Our post on how to report a security vulnerability covers finding the right door.
Quick check
Do I need a working exploit to report a bug?
No. Clear steps, evidence and a credible impact statement are what matter. Proof-of-concept code helps when you have it, but a minimal demonstration is better than a weaponized one.
Should I bundle several findings in one report?
Generally one issue per report is easier to triage, track and credit. Link related reports to each other.
Sources
Last reviewed: 19 October 2026.
