Coordinated Vulnerability Disclosure Explained: How Embargoes Work and Break

When a security bug becomes public before its fix ships, attackers get a head start and defenders have nothing to install. Coordinated vulnerability disclosure exists to close that gap. It is a set of habits for reporting, fixing and publishing a bug in the right order.

That order broke several times in one week of October 2026. The PHP Foundation says a company shipped container images with PHP's fix more than six hours before the agreed release. The next day, Phoronix reported six Linux kernel bug reports on a public mailing list instead of a private one.

Picture a common setup, made up for this guide but typical of real projects. Two volunteers maintain a small open-source library that turns PDF invoices into JSON, and a few hundred companies use it. One morning a stranger emails them: a crafted PDF makes the library read files it should not.

The naive move is to open a public issue and push a fix that afternoon. For a real security bug that is the wrong order, because it shows attackers where to look before any user can update.

The volunteers instead have to decide who to tell, when, and in what order. This guide follows that report from the first email to the public advisory. It leans on the official policies of the Linux kernel, the CERT Coordination Center and GitHub.

Seven terms come up again and again. Each one is explained here once, and the guide uses the same word for it throughout.

• Vulnerability: a bug that lets someone do what they should not, such as read private files or run their own code on your server.
• Finder and maintainer: the finder discovers the bug and reports it. The maintainers, called the vendor in formal texts, own the code and ship the fix.
• Embargo: an agreement to keep a bug private until a set date and time, so the fix and the details come out together.
• Downstream: everyone who repackages the code before users get it, such as Linux distributions, container image builders and cloud providers.
• Advisory: the public notice naming the bug, the affected versions and the fixed version. GitHub calls its version a GitHub Security Advisory, or GHSA.
• CVE and CNA: a CVE is a public ID for one vulnerability, such as CVE-2026-109618. A CNA, or CVE Numbering Authority, is an organisation allowed to assign those IDs.
• Proof of concept (PoC) or reproducer: a small input or program that shows the bug happening. An exploit is a PoC that does real harm.

Coordinated vulnerability disclosure is the process of collecting a bug report from its finder and sharing it with the people who must fix it. It ends by publishing the bug and its fix. That paraphrases the definition in the CERT Guide to Coordinated Vulnerability Disclosure. CERT/CC is the CERT Coordination Center at Carnegie Mellon University.

The CERT guide splits the work into phases: discovery, reporting, validation and prioritisation, remediation, public awareness and deployment. Remediation means building and testing the fix. Deployment means users actually install the fix, which is the step that protects them.

An international standard covers the maintainer's side. ISO/IEC 29147:2018 gives vendors requirements and recommendations for receiving reports and publishing fix information. As of 23 October 2026, ISO lists it as current but due for revision, with a new edition in development.

Most of this guide is established practice that you can check on an official page. People do disagree, mostly about who may break an embargo and when. Where they do, the guide names who holds which view.

Several separate things broke in one week, and each has a first-hand or dated account. This guide covers only the disclosure process. The PHP2Shell guide in the related reading explains the PHP bugs themselves and how to patch them.

Each break came through a different door. A downstream partner and a research firm published too soon. Information spread through people who did not know the rules. A report went to the wrong list. The diagram puts those doors on the normal path of a fix.

The table does not prove that embargoes are failing everywhere. No source here measures how often embargoes break. It shows one busy week in which three different doors opened.

An embargo works by sharing the fix with a small, named group under one agreed date and time. When that moment arrives, the maintainers publish the release and the advisory together. Downstream partners ship their builds at the same time.

Think of a board exam paper. The paper setter is the maintainer, and the printing presses are downstream packagers who get the paper early so every centre has copies. Everyone opens the sealed packet at the same time on exam day, which is the coordinated release.

A leaked paper, like a leaked bug, helps the few who saw it early. Where the picture breaks: a board can set a fresh paper after a leak. A vulnerability cannot be swapped for a new one, so after a leak the best answer is to ship the fix, or at least advice, fast.

The fork in the road matters. A trust boundary is a line between what someone is allowed to do and what they are not. The kernel says its security list exists for urgent bugs that cross one on a correctly configured system and are easy to exploit.

Two clocks: the kernel team and linux-distros

Big projects add a second layer. The Linux kernel's security team fixes the code, while the linux-distros mailing list lets operating system vendors prepare packages. Details are then announced on the public oss-security list. The two groups run different clocks, and the kernel page warns about mixing them.

Note a gap between the two pages. The kernel page says the linux-distros clock starts at the first post. As of its 2 July 2025 revision, the distros wiki page gives the 14-day maximum but does not say what it is counted from.

The kernel page also says the only valid reason to delay a ready fix is to give testing and large rollouts time. Waiting for a conference talk or a press launch is not on that list.

The copy rule changed in May 2026. Commit aed3c3346765, written by Willy Tarreau on 9 May 2026, replaced always copy the security team with the rule for two or fewer recipients. Its message says automated reports had left the team with far more messages than needed.

There is no single number. The kernel allows 7 days from the start of the release process, 14 by exception. The linux-distros list allows at most 14 days, counted from the first post according to the kernel page, and prefers fewer than 7.

The CERT/CC guide's pages on leaks and on independent discovery give no standard length. The independent discovery page does say that a second, independent report of the same bug is a reason to re-evaluate the embargo. An easy-to-find bug may already be known to others, so going public sooner can be safer.

The PHP case shows the cost of a long road before the embargo. The PHP Foundation says the root cause was first noticed in 2024, and fix work stalled for months because the team could not agree on an approach. It calls that a structural failure and is moving to majority decisions.

Here is the invoice library's plan. The day numbers and times are made up, but each step follows the sources above.

You can check the sums yourself. The fix is ready on day 9 and ships on day 14, so the delay is 5 days, inside the kernel's 7. Downstream hears on day 10, so their embargo is 4 days, inside the distros list's preferred 7.

IST is Indian Standard Time, which is UTC plus 5 hours 30 minutes. Always write the release time in UTC first, because every party may sit in a different time zone.

A SECURITY.md is a plain file in your repository that tells finders how to reach you privately. GitHub looks for it in the .github folder first, then the repository root, then the docs folder. It also shows the policy above its private report form.

GitHub's own advice for the file is short: say which versions get security fixes and how to report a vulnerability. The rest of the sample below is our house checklist, not a standard. The menu names in these steps are GitHub's labels as of 23 October 2026.

1. 1

   Write the policy

   Create SECURITY.md with supported versions, the private channel, what to include, your reply time and how you publish. On GitHub, open Security and quality, then Security policy, then Start setup.

2. 2

   Turn on private vulnerability reporting

   On a public repository, open Settings, choose Advanced Security in the Security and quality section, and click Enable next to Private vulnerability reporting. Finders then see a Report a vulnerability button.

3. 3

   Make sure someone is notified

   GitHub notifies admins and security managers when they watch the repository for All Activity or for Security alerts. Check this, or reports can sit unread.

4. 4

   Add a backup email

   Not every finder uses GitHub. A role address such as security at your domain, read by at least two people, still works when one person is on holiday.

5. 5

   Set a default for every repository

   A public repository named .github in your account or organisation can hold a default SECURITY.md. GitHub uses it for every repository without its own file.

This is the invoice library's policy. It is short on purpose, because finders read it in a hurry.

# Security policy

## Supported versions

| Version | Security fixes |
| ------- | -------------- |
| 3.x     | Yes            |
| 2.x     | Until 31 March 2027 |
| 1.x     | No             |

## Reporting a vulnerability

Please do not open a public issue, pull request or discussion for a security bug.

Report it privately in one of two ways:
- Use the "Report a vulnerability" button on this repository's Security and quality tab.
- Or email [email protected] (plain text is fine).

Include the affected version, what goes wrong, and the smallest input that shows it.

## What happens next

- We reply within 3 working days to say we have your report.
- We aim to confirm or reject it within 14 days.
- We fix it privately, then publish the release and the advisory on the same day.
- We will agree a disclosure date with you and credit you unless you ask us not to.

If details become public before the fix, we will release what we have as soon as possible.

Read your own file against the same six points: supported versions, a private channel, a clear do-not-post-publicly line, what to include, a reply time, and how you publish. We ran a small word-search script on the sample and all six were found. A one-line policy saying open an issue missed all six.

A security.txt is a small text file at /.well-known/security.txt on your website that tells finders who to contact. RFC 9116, published by the IETF in April 2022 as an Informational document, defines it.

Two fields are required. Contact gives a mailto:, tel: or https:// address, and you may list several in order of preference. Expires gives a date and time after which the file is stale and should not be used.

Expires must appear only once, and the RFC recommends a date less than a year ahead. The file must be served over HTTPS as text/plain in UTF-8. Optional fields include Policy, Preferred-Languages, Encryption and Canonical, which is the file's own address.

# security.txt for the made-up invoice-parser project
Contact: mailto:[email protected]
Contact: https://invoice-parser.example/report-a-vulnerability
Expires: 2027-04-30T18:30:00Z
Preferred-Languages: en, hi
Policy: https://invoice-parser.example/security-policy
Canonical: https://invoice-parser.example/.well-known/security.txt

The script below checks the required fields. It covers only a small part of the RFC. We wrote it for this guide and ran it on Python 3.10, 3.11, 3.12 and 3.13.

import sys
from datetime import datetime, timezone

# Checks a few RFC 9116 rules for a security.txt file
fields = {}
for line in open(sys.argv[1], encoding="utf-8"):
    line = line.strip()
    if not line or line.startswith("#"):
        continue
    name, _, value = line.partition(":")
    fields.setdefault(name.strip().lower(), []).append(value.strip())

problems = []
if "contact" not in fields:
    problems.append("Contact is required")
for value in fields.get("contact", []):
    if not value.lower().startswith(("mailto:", "tel:", "https://")):
        problems.append("Contact must be a mailto:, tel: or https:// URI")

expires = fields.get("expires", [])
if len(expires) != 1:
    problems.append("Expires must appear exactly once")
else:
    try:
        when = datetime.fromisoformat(expires[0].upper().replace("Z", "+00:00"))
    except ValueError:
        when = None
    if when is None or when.tzinfo is None:
        problems.append("Expires needs a date, a time and a time zone")
    else:
        days = (when - datetime.now(timezone.utc)).days
        if days < 0:
            problems.append("Expires is in the past")
        elif days > 365:
            problems.append("Expires should be under a year away")
        else:
            print("Expires in", days, "days")

print("PASS" if not problems else "FAIL: " + "; ".join(problems))

Save it as check_security_txt.py and run python3 check_security_txt.py followed by the file name. On 23 October 2026 it printed the output below for our sample, for a copy of GitHub's own file and for two broken files.

The two broken files used in the run are tiny, so here they are in full.

# bad_security.txt
Contact: [email protected]
Expires: 2026-09-30T00:00:00Z
Expires: 2027-09-30T00:00:00Z

# stale_security.txt
Contact: mailto:[email protected]
Expires: 2026-10-01T00:00:00Z

$ python3 check_security_txt.py good_security.txt
Expires in 189 days
PASS
$ python3 check_security_txt.py github_security.txt
Expires in 7 days
PASS
$ python3 check_security_txt.py bad_security.txt
FAIL: Contact must be a mailto:, tel: or https:// URI; Expires must appear exactly once
$ python3 check_security_txt.py stale_security.txt
FAIL: Expires is in the past

What just happened? The script read each field, then compared Expires with the current time. The day count depends on when you run it, so expect a different number from 189. The bad file fails because its Contact is a bare email address with no mailto: in front, and it has two Expires lines. The stale file fails because its Expires date has passed.

As of 23 October 2026, GitHub's own file expires on 30 October 2026, only a week ahead. A short Expires is fine when a job renews it automatically. Without that job, the file goes stale and finders are told not to trust it.

Maintainers fix the bug out of public view, then publish the release and the advisory as close together as they can. On GitHub, a draft advisory stays private, and a temporary private fork lets you build the fix without a public branch.

1. 1

   Open a draft advisory

   Fill in the affected versions early, because GitHub will not let you publish or request a CVE without them.

2. 2

   Fix in the temporary private fork

   Write a regression test first, one that fails while the bug exists, then the fix, and look for the same mistake elsewhere. The PHP Foundation's maintainer guide notes that CI, the automatic test runs, does not run in these forks, so test locally.

3. 3

   Request a CVE

   Click Request CVE at the bottom of the advisory. GitHub is a CNA, and requesting an ID does not make the advisory public.

4. 4

   Tell downstream, with a time

   Send the patch only to the packagers who need it, with an exact release time in UTC. Mark how far they may share it.

5. 5

   Release, then publish within the hour

   Merge, tag and release, then click Publish advisory. The PHP Foundation's guide says the gap should be minutes to hours, not days.

6. 6

   Check that it reached users

   Publishing deletes the private fork. GitHub then reviews the advisory before adding it to its Advisory Database and sending Dependabot alerts, which it says can take up to 72 hours.

Add the fixed version before you publish. GitHub warns that without one, Dependabot, its bot that alerts projects about vulnerable dependencies, warns users but cannot suggest a safe version.

CVE timing is where the docs and recent experience disagree. GitHub's docs say it usually reviews CVE requests within 72 hours. Collabora wrote on 15 October 2026 that getting one published took many weeks this year. The PHP Foundation's August guide said requests currently take weeks, and that database review can lag by days or weeks.

The PHP Foundation's advice is to request the CVE but not to hold the fix or release for it. You can add the ID to the advisory later. The kernel security team goes further: it neither assigns CVEs nor requires them for reports or fixes.

When you share with downstream, label how far the material may travel. The CERT/CC guide suggests the Traffic Light Protocol, or TLP. It recommends TLP:AMBER for most cases before disclosure. That means sharing only on a need-to-know basis within the receiving organisation and its clients.

Do not fix silently either. The PHP guide points out that without an advisory, tools such as composer audit, PHP's dependency checker, and Dependabot do not warn users who depend on the old version.

Tell the people running the embargo at once, say exactly what leaked and where, and stop spreading it. Then let them decide the release timing, because a leak usually ends the embargo for everyone.

A leak is rarely the work of bad people. The CERT/CC guide says a leak may be a simple misunderstanding or mismatched expectations, and only in rare cases a malicious act. The Hacker News user in October 2026 had been told by a contact that no embargo existed.

1. 1

   Stop adding detail

   Do not post more, share a proof of concept or clarify in public. CERT/CC notes that even knowing a bug exists in a component can be enough for someone to find it.

2. 2

   Tell the coordinator now

   Write to the maintainers, or to the list that shared the information, straight away. The linux-distros rules require members to report a leak urgently and say how far it went.

3. 3

   Give the facts

   Say what leaked, where, when in UTC, and who may have seen it. Links and screenshots help them judge the damage quickly.

4. 4

   Take it down, but assume copies

   Delete or edit the post if you can, then assume someone copied it. In the PHP case, copies of the leaked video spread on social media.

5. 5

   Let them choose the timing

   CERT/CC says a leaked embargo is effectively moot, and everyone should be ready to go public with whatever advice exists. PHP moved its release a day earlier.

6. 6

   Own it and fix the cause

   Apologise plainly, then change what let it happen, such as who gets embargoed mail or how builds are gated. The distros rules ask members to report the measures they took.

If you are the maintainer who hears about a leak, do the mirror image. Publish what you have: the fix if it is ready, or at least a note that you are working on it, so defenders can plan. CERT/CC does not recommend punishing the leaker, though you may choose whom you share with next time.

When many people run similar tools on the same code, they tend to find the same bugs at the same time. A secret held by one finder is then not much of a secret. That is the Linux kernel security team's stated experience, not a measured study.

Pause and predict before reading on: if you found a kernel bug with AI-assisted research, would the kernel team want it handled privately or in public?

Since May 2026, the kernel's security-bugs page says: "If you resorted to AI assistance to identify a bug, you must treat it as public". It explains that such bugs systematically surface across multiple researchers, often on the same day.

Treat-as-public does not mean posting the exploit. The page asks you not to share a reproducer publicly, only to say that one exists so maintainers can ask for it privately. It also lists AI-based tools as a good reason to think an issue may already be public.

In practice, the page expects such a report to be posted to a public list rather than kept on the private security list. Its AI section says the reproducer should be shared only on request, since the report will be posted to a public list.

The rule was added by commit a03ef333fbd6, written by Willy Tarreau on 9 May 2026. It was merged into the main kernel tree on 15 May 2026, during the Linux 7.1 release candidates.

A sister commit in the same series set requirements for AI-assisted reports. Reports should be short and in plain text, state verifiable impact, include a tested reproducer and propose a tested fix. The fix needs a Fixes: tag, a line naming the commit that introduced the bug.

Do not read the October kernel posts as an example of this rule. Phoronix called them seemingly accidental and did not say how the bugs were found, so the link between the two is unknown.

Other projects describe the same pressure in their own words. The PHP Foundation says that since 1 July 2026 it has published 15 CVEs and worked through more than 100 invalid, duplicate or unreproducible reports. Collabora says it has reviewed, fixed and shipped around ten years' worth of security reports so far this year.

As of 23 October 2026, GitHub's private report form has an optional box labelled I used AI assistance to find or write up this report. In our reading, ticking it honestly tells maintainers what the kernel rule assumes: other people may find this bug soon.

Treat it as designing a pipeline with a deadline: one intake, a private work area, a small trusted group and one synchronised release. The interviewer wants to hear the trade-off between time for a good fix and the risk of a leak.

1. 1

   Start with intake

   One private channel, published in SECURITY.md and security.txt, watched by at least two people with a reply target.

2. 2

   Triage against a threat model

   Decide whether the bug really crosses a trust boundary. Ordinary bugs go to the public tracker, which keeps the private queue small.

3. 3

   Fix in a private space

   Use a private fork or branch and run tests locally, so no public CI log hints at the bug.

4. 4

   Coordinate downstream with a dated embargo

   Share on a need-to-know basis with a TLP label and an exact UTC release time, inside a 7 to 14 day ceiling.

5. 5

   Release and advise together

   Tag the release and publish the advisory within the hour, with the fixed version listed so scanners can act.

6. 6

   Plan for the leak

   Keep a short advisory draft ready and a person on call. The rule is simple: if it leaks, ship what you have.