Treat the embargo as over. Acknowledge publicly, give customers any mitigation you have, speed up the fix, and publish an advisory as soon as there is something actionable. The CERT Guide to CVD advises moving to public awareness, accelerating the fix, and avoiding punishment of perceived leakers.
What counts as public too early
Several things end an embargo: the reporter publishes early, a third party posts the details, a patch in an open repository gives the bug away, or you see exploitation in the wild. The CERT Guide to Coordinated Vulnerability Disclosure says that evidence of exploitation during an embargo effectively ends it, and that parties should be ready to go public with whatever advice exists.
The first-day checklist
- Confirm what is public. Read the post. Is it your product, your version, and a real flaw?
- Gather the team. Name an incident lead, a fixer, and a person who writes to customers.
- Check for exploitation. Review logs for the patterns in the public write-up.
- Find a mitigation. A configuration change, a feature switch, a firewall rule, or a temporary disablement. Even a partial one is useful.
- Post an acknowledgement. Say you are aware, what you know, what customers can do now, and when you will update.
- Accelerate the fix. Cut scope to the smallest safe change, test it, and ship a patch release.
- Publish an advisory with affected versions, the fixed version once it exists, and workarounds.
- Update the reporter. Thank them even if the timing was not what you agreed.
What the acknowledgement should and should not say
| Say | Avoid |
|---|---|
| What you know and do not know yet | Guesses about attackers |
| Which versions are affected | Playing down real impact |
| A mitigation customers can apply | Blaming the reporter |
| When the next update comes | A fixed ship date you cannot guarantee |
Do not punish the leaker
The guide recommends avoiding punishing perceived leakers. Often the leak was a mistake: a public issue tracker, a conference slide, a patch commit. Look at your own process first. If a commit message exposes a vulnerability before release, change how your team writes commits for security fixes.
After the dust settles
Write a short review: how the information got out, how long to acknowledge, how long to mitigate, how long to fix, and what to change. Update your policy with whatever surprised you. The post on running a review after a fix lists questions to ask.
Try it yourself
The zero-day watch demo shows how a newly public weakness is tracked from the first signal to a list of affected assets. Click through it and note how fast the picture changes.
Click through it at your own pace, or open it full screen.
Quick check
Should we publish an advisory before the fix exists?
If customers can reduce risk with a mitigation, yes, and say the fix is in progress. If nothing can be done yet, an acknowledgement with a date for the next update is still better than silence.
Can we ask a site to take the post down?
You can ask, but the guide notes that suppressing coverage tends to amplify it. Provide accurate facts instead.
Safeguard's zero-day discovery and asset discovery can help you find which of your own systems run an affected component. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
