Responsible Vulnerability Disclosure
The idea
If you discover a security flaw, the goal is to get it fixed without putting users at risk. Coordinated vulnerability disclosure (CVD) means telling the vendor or owner privately, working with them on a fix and publishing details after users can protect themselves.
Before you report: stay safe
- Stop testing once you have proof of concept; do not download, change or keep other people's data.
- Test only what is in scope if a programme exists. Without permission, even good-faith testing can be unlawful — see ethical hacking vs malicious hacking.
- Never demand payment as a condition of not disclosing; that can be extortion.
Find the right channel
- Look for a
security.txtfile at/.well-known/security.txt(RFC 9116). - Check for a "Responsible Disclosure" or bug-bounty page. Ours is at /legal/responsible-disclosure.
- If there is no contact, a national CERT or a coordinator such as CERT/CC can help.
Write a useful report
| Include | Why |
|---|---|
| Affected product, URL, version | So they can reproduce |
| Clear steps to reproduce | Saves time |
| Impact in plain language | Helps prioritise |
| Proof (screenshots, minimal PoC) | Verifies the issue |
| Suggested fix (optional) | Speeds remediation |
| Your contact details and preferred disclosure date | Enables follow-up |
Encrypt sensitive details when a PGP key is offered.
Timelines
Many coordinators use a fixed period (commonly 45–90 days) before public disclosure, extended when a fix is in progress. ISO/IEC 29147 and 30111 describe vulnerability disclosure and handling processes for organisations.
After the fix
Vendors may request a CVE ID through a CVE Numbering Authority. Track published CVEs in our vulnerability database and read advisories carefully — see how to read a security advisory.
If you run a service
Publish a security contact, acknowledge reports quickly and consider a safe-harbour statement for good-faith research.
Use techniques only on systems you are authorised to test.