A Vulnerability Is Public Before Your Fix: A First 48 Hours Playbook

Microsoft's 13 October 2026 Patch Tuesday fixed 1,413 CVEs, and SecurityWeek reported that two of them had been publicly disclosed before patches were available. One was CVE-2026-108398, a Windows Defender Application Control bypass that Microsoft believes is unlikely to be exploited. The other was CVE-2026-92707, a denial of service flaw in the MessagePack-CSharp component affecting Visual Studio and .NET, with exploitability not yet assessed.

Large vendors absorb this routinely. For a ten person team it is a bad day: a researcher's blog post, a public GitHub issue or a social media thread describes your bug and your fix is not ready.

What's affected

Any vendor or maintainer whose vulnerability becomes public without a patch. Common routes: a reporter loses patience, a third party finds the same bug independently, a customer posts logs, or a public issue is filed by someone who does not know your private channel.

The two Microsoft cases show the range. One is rated unlikely to be exploited. The other had no exploitability assessment at publication. The right response depends on that distinction, and you can only make it if you check quickly.

How to check if you're exposed

Set up listening before you need it.

gh search issues "vulnerability OR exploit OR CVE" --repo example-org/example-repo --state open

Also set an alert on your product name combined with words such as vulnerability, RCE and bypass, in whatever feed reader or alert tool your team already uses.

Then confirm three facts as soon as you see a public post. Is it real? Can you reproduce it? Is anyone exploiting it?

What to do now

1. Hour 0 to 2: assign an incident owner. Save a copy of the public post with a timestamp. Do not reply publicly yet.
2. Reproduce on a current build. Decide whether it is valid, and what an attacker gains.
3. Check for exploitation in your logs and telemetry. If you find evidence of active exploitation, write down the time you established it. Under the EU CRA, Article 14 requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability in an in-scope product, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
4. Hour 2 to 8: publish a short acknowledgment where the discussion is happening: "We are aware, we are investigating, here is where to follow updates." Contact the researcher if there is a way, and ask for coordination from here on.
5. Ship a mitigation if a patch is days away: a configuration change, a feature flag, a WAF rule, or removal of the vulnerable endpoint. Document it as a mitigation, not a fix.
6. Request a CVE ID so scanners and customers can track it. If a CNA with scope exists, go there first.
7. Within 48 hours: publish an advisory with affected versions, impact, workaround and when you expect the fix. The OpenSSF guide says that if a complete fix is not ready, release a patch that breaks the exploitation chain and say it is partial. If it cannot be fixed at all, disclose with workarounds.
8. Ship the fix, update the advisory, and tell customers how to confirm they are on a fixed version.

How to avoid this trap

1. Keep a documented private channel and make it easy to find. Public issues often appear because the private route was unclear.
2. Acknowledge fast. The OpenSSF guide recommends 1 to 2 days. A reporter who sees a reply is less likely to publish.
3. Pre-write an advisory template and a customer notice so the first public statement takes minutes.
4. Know your mitigation menu per component in advance: which endpoints can be disabled, which flags exist.
5. Keep log retention long enough to answer "were we exploited before the report."

Why it matters

The OpenSSF guide observes that withholding exploit details helps only for a few days, because attackers can often infer the attack from a patch. Once something is public, the window is shorter still. Your goal moves from secrecy to speed and clarity.

Customers forgive a leak that is handled openly. They do not forgive silence, or a statement that says there is no risk when you have not checked.

Try it yourself

Take one open dependency vulnerability in your own project and write the advisory paragraph you would publish if it were public today: affected versions, workaround, expected fix date. Then look at how a fix is found and applied in the walkthrough below.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• SecurityWeek: Microsoft patches record 1,413 vulnerabilities, 14 October 2026
• OpenSSF guide for maintainers
• Regulation (EU) 2024/2847, Article 14