Should you publish a vulnerability you found? A decision guide

Publish only after you have tried to report privately, given the vendor a stated and reasonable period, and considered who is exposed in the meantime. Published norms range from 90 days to 7 days for exploited bugs. If you are unsure, use a coordinator and take legal advice.

Question 1: did you tell the vendor?

Publishing without telling anyone is full disclosure, and most guidance treats it as a last resort. OWASP says researchers often set a deadline and may move to full disclosure if it is missed. Start with a private report. See what to put in a vulnerability report.

Question 2: what deadline did you give?

Say your plan in the first message, in a non-threatening tone, as OWASP advises. Published reference points:

• Project Zero gives vendors 90 days to make a patch available, with a grace period of up to 14 more days on request. If a patch ships in time, details are public 30 days after users receive it.
• For issues exploited in the wild, Project Zero's policy replaces the 90 day deadline with 7 days.
• CISA says it may disclose as early as 45 days after first contact when a vendor is unresponsive.
• The linux-distros list caps embargoes at 14 days.

For the comparison in detail, see disclosure deadlines compared.

Question 3: is there a fix?

If a patch is available and users have had time to apply it, publishing details carries less risk. If no fix exists, publishing hands attackers a head start. Project Zero's 30 day gap after a patch is designed around this idea, giving users time to install.

Question 4: is it already exploited?

If you have credible evidence of exploitation, defenders need to know quickly. Project Zero's shorter 7 day deadline reflects that. In that case consider telling a coordinator or the vendor immediately and agree on a short timeline.

Question 5: who is exposed, and can they protect themselves?

Think about the people running the software. If they can apply a simple workaround, a public note helps them. If they cannot, and the bug is easy to exploit, hold back detail and publish a high level warning with mitigations.

Question 6: what are the legal and personal risks?

Laws differ by country, and a vendor's terms may add limits. Check whether the vendor has a disclosure policy with safe harbor language. See safe harbor language in a VDP. Do not threaten, and do not ask for payment before revealing details unless there is a bug bounty program, as OWASP says. If in doubt, get legal advice.

A short flow

1. Report privately with a stated period.
2. Follow up politely. OWASP notes fixes inside enterprises take more time than researchers expect.
3. Escalate to a coordinator if there is no reply.
4. Publish when the period ends, with a clear account of what you did, or earlier by agreement.

If you are on the receiving side, see what to do when the first vulnerability report arrives. Safeguard's dependency scanning can show developers whether a published flaw affects their projects.

Quick check

Sources

• Project Zero vulnerability disclosure policy
• OWASP Vulnerability Disclosure Cheat Sheet
• CISA Coordinated Vulnerability Disclosure process
• Openwall oss-security wiki, distros list rules

Last reviewed: 19 October 2026.