If details of an unfixed vulnerability appear publicly, confirm the report, ship any mitigation you can, tell affected customers what to do now, and talk to the researcher without blame. Speed and clear communication matter more than arguing about who broke the timeline.
Why it happens
Deadlines expire. Project Zero's policy publishes details 90 days after notification if no patch exists, and CISA says it may disclose as early as 45 days after the first attempt to contact an unresponsive vendor. Researchers also go public when they believe a flaw is already being exploited, or when they feel ignored. Some publish by accident, or a third party leaks it. Knowing which case you face shapes the response.
First hour: confirm and gather
- Read what was published. Is it accurate? Is there working exploit code?
- Check your records. Did you receive a report earlier? Did anyone reply?
- Check logs and telemetry for signs of exploitation.
- Wake the people you need: an engineer who knows the component, someone for communications, and the person who can approve a release.
If a report was sitting unanswered in a shared inbox, say so inside the team and fix the process after the incident.
Hours two to six: mitigate
Look for anything that reduces exposure before a full patch:
- A configuration change or feature switch that disables the vulnerable path.
- A rule on your edge to block the exploit pattern. Treat this as temporary, since attackers adapt.
- Revoking or rotating credentials that could be exposed.
- Restricting access to the affected feature for high risk customers.
Test the mitigation. A bad workaround that breaks your service creates a second incident.
By the end of the day: communicate
Tell customers early, even if the fix is not ready. The message should say:
- What is affected.
- What you know about exploitation.
- What they should do now.
- When you will update them next.
Avoid minimising language. Do not claim no customers are affected unless you checked. If you are unsure, say what you checked and when.
Publish an advisory page and update it as things change. The OWASP guidance says advisories should include a summary and impact, vulnerable and patched versions, caveats and workarounds, and a CVE ID where assigned.
Talk to the researcher
The OWASP guidance says to stay professional, never threaten legal action, and keep reporters informed. Contact them, thank them, and ask what they have seen. They may know details about exploitation or about variants you have missed. If the disclosure broke an agreed timeline, raise it calmly later, after the fix, not in the middle of the incident.
Fix and follow through
- Set a fix target with an owner and a release plan.
- Agree credit with the researcher.
- Request a CVE ID if the flaw affects distributed software.
- After release, publish the timeline, including your own delays.
After the incident
Review three questions:
- Why did the report not reach a person sooner?
- Why did the fix take longer than the deadline?
- What would let us ship mitigations faster next time?
CISA's directive suggests tracking timelines for acknowledgment, assessment and resolution. Use the same measures internally.
Quick check
Should we ask the researcher to take the post down?
You can ask, politely, but expect refusal if the deadline passed. Concentrate on protecting users.
Do we have to notify customers if no exploit is known?
That depends on contracts and law, so check with counsel. Even when it is not required, early notice usually builds trust.
Sources
- Project Zero disclosure policy
- CISA coordinated vulnerability disclosure process
- OWASP Vulnerability Disclosure Cheat Sheet
- CISA BOD 20-01
Last reviewed: 19 October 2026.
