Pre-disclosure embargo and CVE coordination

TL;DR: Pre-disclosure embargoes are temporary contracts of silence between a researcher, the vendor, and sometimes downstream consumers, designed to give defenders time to ship a patch before attackers see a writeup. CVE coordination layers on top: a CNA (CVE Numbering Authority) reserves an ID, the vendor publishes an advisory, and the researcher publishes a PoC on the agreed date. Get the agreement wrong and you either burn users (early leak) or burn yourself (vendor sits on the bug forever). Companion notes: responsible-disclosure-across-jurisdictions, disclosure-and-comms, and one-day-from-patch-diff for the attacker view of post-embargo windows.

Why it matters

A bug-bounty hunter who finds a real 0-day in a widely-deployed product is suddenly a temporary insider on a security incident. Whether you handle it well determines:

Whether real users get exploited during the disclosure window.
Whether you get sued, gagged, or de-platformed (see responsible-disclosure-across-jurisdictions).
Whether the vendor pays, credits you, and lets you publish.
Whether the CVE ends up with your name, an anonymous tag, or someone else’s name.
How much leverage you have if the vendor stalls past the deadline.

This is not just an ethics topic. It is operational risk management for the researcher, and getting the mechanics right is how senior hunters in case-study-google-vrp-writeup-patterns and case-study-orange-tsai-research-pattern consistently land high-impact disclosures without losing control of their own findings.

Embargo agreement structure

An embargo is just a written understanding. It does not need to be a formal contract, but it should be explicit in writing (email is fine). The minimum elements:

Core terms

Scope of the secret. Exactly which bug(s), which products, which versions. If you find a second bug later, it is not automatically under the same embargo.
Embargo end date. A specific calendar date and timezone, e.g. “2026-09-15 1700 UTC”. Not “when the patch ships” without a hard cap, that is how 6-month silences happen.
What both sides can say after embargo lifts. PoC publication, blog post, conference talk, social media post.
Credit line. Exact name/handle, link to your profile or company, whether the credit appears in the advisory.
CVE handling. Who requests the CVE, which CNA, who fills in the CVSS, who writes the description.
Escalation path. Named human contacts on both sides, not just security@.

Standard timelines

90 days is the de-facto industry standard, popularised by Google Project Zero and now used by many programs.
30 days for actively-exploited bugs if there is evidence of in-the-wild abuse.
120 days is reasonable for complex hardware, firmware, or multi-vendor coordination (see firmware-audit-methodology, ics-scada-protocols-attacks).
14-day grace period after the deadline if a patch is imminent. Project Zero documents this publicly and many CNAs respect the pattern.

If the program wants 180+ days for a simple web bug, that is a negotiation, not an obligation.

CVE assignment mechanics

CNAs and MITRE

MITRE is the root CNA and runs the CVE program. They assign IDs of last resort when no vendor CNA exists.
Vendor CNAs (Microsoft, Apple, Google, Cisco, Oracle, etc.) assign CVEs for their own products. Always preferred when available.
Third-party CNAs like GitHub, HackerOne, and Bugcrowd can assign CVEs for products not covered by a vendor CNA. Useful when the vendor refuses to engage.
CNA-LR (Last Resort) is MITRE’s catch-all for everything else.

The CVE list of CNAs is public at the CVE program site; check it before negotiating, since who owns the ID changes the dynamics.

Vendor-CNA vs researcher-CNA dynamics

When the vendor is the CNA, they control:

The CVE description text (often watered down).
The CVSS vector (often downgraded).
The timing of public listing.
Whether your handle appears.

You can push back, but their CNA, their call. Document everything in case you need to publish your own writeup with a corrected analysis later (see report-writing-step-by-step).

When a third-party CNA (e.g. GitHub Security Lab) handles it, you usually get more neutral framing. Researchers often prefer this for open-source bugs where the upstream maintainer is a single person without security tooling.

Multi-vendor coordination

The hard case: a bug in a shared library, protocol, or upstream component used by many vendors. Examples include Log4Shell, OpenSSL bugs, libcurl bugs, BGP/DNS protocol issues, and shared baseband stacks (see android-baseband-attacks, ios-baseband-attacks).

Process

Identify the upstream maintainer. Patch them first if possible.
Contact a coordinator. CERT/CC, the upstream project’s security team, or a national CSIRT. They have established multi-vendor pre-notification lists.
Agree on a single coordinated release date across all affected vendors.
Stagger the technical detail. Vendors get full PoC; the public initially gets only mitigation guidance and CVE IDs.
Pre-disclosure list mechanics. Some lists (linux-distros, openssl-announce) require NDA-equivalent commitments before you can share.

The tradeoff: more vendors in the loop means more leak surface. Keep the list as small as the product matrix demands.

When to publish the PoC

PoC timing is the most common embargo failure point. A few guidelines:

Day 0 of public advisory: safe to publish a high-level description, screenshots, and impact analysis.
Day 0 to Day 7: wait before dropping a one-click exploit, especially for internet-exposed services. Defenders need time to patch (see n-day-rapid-exploitation for the attacker side of this window).
Day 14-30: full PoC, technical deep-dive, and conference talk slides.
Never publish before the embargo lifts, even if the vendor leaks first; let them be the one in the wrong, not you.

For widely deployed enterprise gear (firewalls, VPN appliances, ICS), many researchers now hold PoCs indefinitely or until patch adoption telemetry crosses a threshold. This is increasingly standard practice and aligns with the playbook in one-day-from-patch-diff where attackers weaponise diffs within hours.

The “subtweet trap” is real. Things that look harmless but break embargoes:

“Big disclosure coming soon, vendor starts with M” — narrows the search space.
Cryptic screenshots of debugger output, even if cropped.
Liking or retweeting other researchers’ speculation.
Posting a CVE ID before the official advisory drops, even if you have it reserved.
Conference CFP submissions that name the product and bug class before embargo lift.

Operational rule: assume every account you control is monitored by threat intel teams who will correlate. If you must build hype, do it after the patch ships.

Embargo violations by third parties

Sometimes someone else leaks. Options:

Vendor leaks early (e.g. accidental advisory publication). You are now free to publish, but call them and confirm in writing.
Another researcher publishes independently. If they found it independently and disclosed responsibly, accept parallel disclosure gracefully. If they got the info from a leak, document the chain and escalate to the CNA.
Exploitation observed in the wild. Embargo is effectively over; coordinate an emergency advisory. This is the canonical exception, recognised by Project Zero, CERT/CC, and most major CNAs.
Patch diff is published before advisory. Common with open-source projects. See one-day-from-patch-diff for how fast attackers move, and push the vendor to issue advisory immediately.

Do not retaliate publicly. Document privately, and let the coordinator handle social pressure.

Embargo exceptions for active exploitation

The clearest exception to a standard embargo is in-the-wild exploitation. If you or anyone can show evidence:

Honeypot or telemetry showing exploit attempts.
Threat intel report from a reputable vendor.
Compromise of a known target.
Sample in VirusTotal or a malware feed.

Then the embargo shortens, often to 7 days or less. CISA’s Known Exploited Vulnerabilities (KEV) catalog and ENISA advisories are useful pressure tools to push vendors to ship faster. This also intersects with apt-tradecraft-chinese-mss and apt-tradecraft-russian-svr-fsb style operations where 0-days are observed before researcher disclosure.

Defensive baseline

For program owners and CNAs reading this, the baseline for not burning researchers:

Acknowledge reports within 72 hours.
Provide a status update at least every 14 days.
Commit to a calendar deadline, not “when we get to it”.
Honour the credit line as written.
Do not silently widen the embargo to cover related bugs the researcher didn’t find.
Publish a public security policy with PGP key and CNA scope.

For researchers, the baseline:

Never share details outside the agreed channel.
Keep PoCs in encrypted storage; assume your laptop is a target.
Don’t use the bug yourself for unrelated work or other clients.
Don’t hint about the bug publicly.

Workflow to study

Pick a recent high-profile coordinated disclosure (e.g. a CISA KEV entry or a Project Zero post). Reconstruct the timeline from initial report to PoC publication.
Read 5 vendor security policies for programs you target. Note their stated embargo terms, CNA status, and contact channels.
Practice drafting an embargo email. Include scope, deadline, credit, CVE handling, and escalation. Compare your draft against the CERT/CC vulnerability reporting template.
Walk through MITRE’s CVE request form for a hypothetical bug. Note which fields are required and which are negotiable.
Find a parallel-disclosure case (two researchers reporting the same bug). Study how the vendor handled credit and how the researchers communicated publicly.
Tabletop an embargo violation. What do you do at hour 1, hour 6, day 1 if someone tweets your bug class? See disclosure-and-comms.
Cross-reference with responsible-disclosure-across-jurisdictions to understand which countries treat embargo breaches as breach-of-contract vs criminal computer misuse.