Last week two critical flaws in PHP, nicknamed PHP2Shell, made the news. Besides the bugs themselves there was a fight over the “embargo”: Chainguard released patched container images hours before the agreed date and the PHP Foundation was not happy about it (The New Stack has the story).

I was curious about how vulnerability disclosures work, so I asked Claude to briefly describe the steps of the process and the official terms used in industry.

The process

The usual model is called coordinated vulnerability disclosure (CVD). Roughly:

  1. The finder reports the bug privately to the maintainer, for example through a security@ address, a security.txt file, a GitHub private advisory or a bug-bounty platform.
  2. The maintainer confirms it, gets a CVE ID, scores its severity and builds a fix in private.
  3. Downstream vendors (Linux distros, container image vendors, cloud providers) get the details and the patches under embargo, so they can prepare updates. For example, Openwall’s linux-distros list allows an embargo of at most 14 days and prefers less than 7.
  4. On the agreed release date, the advisory, the fixed versions and the distro updates all go public together.
  5. Later, the full technical write-up and the proof of concept are published. Google Project Zero, for example, waits 30 days after the patch is available.

Most policies let the release move earlier if the bug is being exploited in the wild, and once it has leaked there is little left to protect. CERT/CC lists active exploitation as a reason to publish early, and Project Zero shortens its deadline to 7 days for bugs exploited in the wild. This is the clause Chainguard invoked in the PHP2Shell case. The argument was about whether the evidence of exploitation was strong enough.

Finders also often set a deadline so that vendors can’t sit on bugs forever: Project Zero’s is 90 days, CERT/CC’s is 45 days.

Terms

Term Meaning
Coordinated vulnerability disclosure (CVD) The whole process above. The older name, “responsible disclosure”, is now mostly avoided because it implies that anyone who doesn’t follow it is irresponsible.
Full disclosure Publishing everything right away, without coordinating with the vendor
Embargo / embargo period The window when the bug is kept secret within a small group: the maintainers, the finders and selected downstream vendors
Coordinated release date (CRD) / embargo lift The agreed moment of publication
Embargo break / leak Publishing before the agreed date, on purpose or by accident
Pre-notification Briefing downstream vendors privately before the release
Pre-announcement A public heads-up (“a critical fix ships on Thursday”) with no technical details
Disclosure deadline The longest the finder will wait before going public anyway
Security advisory The official public write-up of the vulnerability
CVE The vulnerability’s public ID, e.g. CVE-2026-109618
CVSS A severity score from 0 to 10
Zero-day (0-day) A bug that attackers know about, and often exploit, before a fix exists
N-day / 1-day A bug that is already known and patched, exploited on systems that haven’t updated yet
Patch diffing Reverse-engineering a fix to find the bug it fixes
Patch gap The time between a fix becoming visible (e.g. a public commit) and users actually getting it
Exploited in the wild (ITW) Real attacks, as opposed to lab proofs of concept
PoC A proof-of-concept exploit

Formal references