Ask early, in writing, with a specific reason, a revised date and proof of progress. Treat the embargo as a courtesy the reporter gives you, not a right. The CERT Guide to CVD says the reporter or coordinator may decline, and that cooperative, reasonably explained delays are the ones most often accepted.
What the guidance says
In the vendor troubleshooting scenarios, the CERT Guide to Coordinated Vulnerability Disclosure says that when a vendor is not ready before the embargo expires, it should request an extension from the reporter or coordinator, and recognise that the embargo is a courtesy the reporter may decline. From the reporter side, it says to weigh the vendor's responsiveness and good faith, extend for a cooperative vendor with a reasonable explanation, and never wait indefinitely.
When to ask
Ask as soon as you know the date will slip, not on the final day. A request a week out reads as planning. A request on the deadline reads as a surprise.
What to include
- The new date, specific and realistic.
- The reason, concrete: a fix requires a change across three services, a dependency maintainer needs time, a release train runs on the 12th.
- Progress so far, such as reproduced, root cause found, fix in review.
- What you are doing in the meantime, for example a mitigation customers can use.
- A next checkpoint, so the reporter sees movement.
- An offer, such as letting them test the fix first.
Template
We are going to miss the 15th. The fix touches the session service and the gateway, and the second change needs a full regression pass. We have reproduced the issue, merged a test, and the fix is in review. We would like to ship on the 29th and will write on the 22nd with a status. In the meantime customers can disable the legacy endpoint, which closes the path in your report. Would you be willing to extend to the 29th?
What to do if they say no
Accept it. Then:
- Publish an advisory on their date with the mitigation, even without a full fix.
- Tell customers what to do now.
- Thank the reporter for the notice.
- Keep working; do not sour the relationship.
When an extension is a bad idea
An extension is hard to defend when there is evidence of exploitation, when the reporter has already waited a long time, or when your explanation is vague. The guidance says embargoes should not run forever.
| Situation | Likely outcome |
|---|---|
| Real work in progress, clear reason, early ask | Often granted |
| Vague reason, late ask | Likely declined |
| Exploitation seen | Embargo effectively over |
| Third extension request | Expect resistance |
Quick check
How long an extension is reasonable?
It depends on the fix. Ask for what you need plus a margin, and offer interim checkpoints. Long extensions with no visible progress rarely land well.
Should we offer anything in return?
Early access to the fix for testing and clear public credit cost little and show good faith.
Related
See disclosure deadlines of 90, 30 and 45 days explained for how common timelines work. Safeguard's autonomous remediation with fix PRs, which is off by default, can speed the dependency part of a fix once you decide to enable it. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
