A vulnerability was reported in a public issue: what to do

Treat a vulnerability posted in a public issue as a high-priority bug that attackers can already see. Reproduce it, ship a fix as fast as is safe, tell your users clearly, and then fix your intake so reporters know where to go. The usual embargo no longer applies, but good communication still does.

First hour

The OpenSSF maintainer guide says public disclosure without contact should be treated as a high-priority regular issue, with clear communication to users. In practice:

1. Read it carefully. Decide whether it is real, using the triage questions.
2. Decide on the issue itself. Editing out the exploit steps can reduce copying, but the original text may already be cached or forked. Do not rely on it. Do not delete the issue without a record, because you will want the history for the advisory.
3. Thank the reporter and ask whether they have a patch idea. Many people post publicly because they could not find a private path.

Fix quickly, not carelessly

Without an embargo, the clock is the problem. Options for a short-term fix:

• A minimal patch that breaks the exploit chain, with a fuller fix later. The guide describes this approach for stalled patches.
• A documented workaround, such as a configuration change, if a code fix will take time.
• A release marked clearly as a security release.

Keep the patch small. Large refactors in a rush create new bugs.

Tell users

Withholding details helps only for a few days at most, per the guide, and here it is already public. So publish:

• An advisory saying what is affected, which versions are fixed, and what to do now.
• A line in the release notes.
• A request for a CVE if it qualifies. See requesting a CVE with GitHub advisories.

If you suspect active exploitation, say so and prioritise the notice.

Fix the reason it happened

People post vulnerabilities publicly for many reasons. Some did not know your policy, could not find a private channel, or got no reply last time. You can fix those.

• Add a SECURITY.md. See writing one.
• Enable private vulnerability reporting.
• Add an issue template that points security reports to the private route.
• Keep an acknowledgement habit, so silence does not push people public.

Do not punish the reporter

It is tempting to scold. Resist it. A short, kind note with the link to your policy works better, and the next report from that person may be private.

Quick check

Sources

• OpenSSF maintainer guide for vulnerability reports

Last reviewed: 19 October 2026.