Subscribe
Policy
9 min read
axc
axc

Who Decides When an AI-Found Bug Goes Public? Disclosure Rules After PHP2Shell

The PHP2Shell embargo dispute, read against the rules. What CISA's disclosure program, CERT/CC guidance, ISO/IEC 29147 and 30111, and the EU Cyber Resilience Act say about ending an embargo early, and what they do not say about bugs found by AI.

Olivetti-style poster with the title PHP2SHELL DISCLOSURE RULES, a padlock, a calendar and document icons
Olivetti-style poster with the title PHP2SHELL DISCLOSURE RULES, a padlock, a calendar and document icons

The two PHP flaws known as php2shell were found with help from AI models, patched on October 21, and disclosed after a coordinated plan broke down in its last two days. Our news explainer on PHP2Shell covers the bugs, the patches and the timeline. This post covers the policy question behind the dispute: who sets a disclosure date, what the written rules say about ending an embargo early, and whether any of those rules treat a bug found by AI differently.

The short answer from the documents below: most of the rules that govern disclosure timing are norms and voluntary policies, not law. The one binding law in this set, the EU Cyber Resilience Act (CRA), sets duties to report to authorities and to component maintainers. The CRA articles cited here do not set a date for public release.

The dispute, as each side states it

The PHP Foundation's post about the release says coordinated disclosure "worked well until 2 days ahead of the targeted release date." In its account, the CVE IDs began circulating on October 20 with a wrong release time and score, PHP moved the release forward one day, and security firm Calif "mistakenly published a video" of its proof of concept. The foundation adds that mitigation advice it gave "a few critical infrastructure providers" around 23:00 UTC on October 20 "may have leaked as well." It then says that on October 21 at 07:41 UTC, "more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix."

Chainguard's chief executive, Dan Lorenc, gave his side to The Register. The Register reports that he did not dispute the timeline but said the company "didn't leak." He said he notified the PHP coordinated disclosure channel of his plans and shipped because "People were getting hit in advance" of the official disclosure. He described the norm this way: "It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild."

This post does not decide who was right. It sets out what each relevant rule or policy says, and where the facts in the sources differ.

Who sets the date: maintainers, by agreement

None of the documents reviewed here lets a government agency set the date on which an open-source project ships its fix. In this case the PHP project set the date and later moved it. Its pre-announcement of October 20 gave a release time of 14:00 UTC on October 21 and added: "We reserve the right to release earlier if details of either vulnerability become public, or if we see evidence of active exploitation in the wild."

Distributors who receive a patch early agree to hold it. The PHP Foundation says Chainguard, "Like other distributors," had received the patch in advance "so its users could update the moment the vulnerabilities were disclosed."

OpenAI, which helped coordinate the response through its Patch the Planet program, leaves advance notice to maintainers. In its proposed framework, OpenAI writes that the same criteria would apply to comparable organizations, "with maintainers deciding whom to involve ahead of disclosure."

CISA: a coordination program, not a release authority

The US Cybersecurity and Infrastructure Security Agency runs a Coordinated Vulnerability Disclosure (CVD) program. CISA says the program "facilitates the timely and synchronized dissemination of vulnerability information" so that reporters, manufacturers, maintainers, users and service providers "receive critical information simultaneously." The page lists open source software and artificial intelligence among the technologies whose vulnerabilities it coordinates.

CISA cites its authority to "receive information" about vulnerabilities under 6 U.S.C. 659(c)(12), and says the Secretary of Homeland Security "may develop and adhere to Department policies and procedures for coordinating vulnerability disclosures" under 6 U.S.C. 659(n).

On timing, CISA lists four factors: whether the vulnerability is already public or actively exploited, potential impact, vendor responsiveness, and whether mitigations are available. Its one fixed number applies to unresponsive vendors: CISA "may disclose vulnerabilities as early as 45 days after the initial attempt to contact the vendor is made, regardless of the availability of a patch or update."

These rules apply to cases reported to CISA. The sources do not say that PHP2Shell went through CISA's CVD process. OpenAI says it engaged CISA, the Office of the National Cyber Director and "the White House's Super Intelligence Force" to help guidance reach critical organizations.

CISA's public role on October 21 was an alert telling organizations to patch immediately. It said: "While CISA has not observed exploitation of these vulnerabilities as of the time of publication, they pose a risk to organizations if left unpatched." The UK National Cyber Security Centre and the Canadian Centre for Cyber Security issued their own patch guidance the same day.

CERT/CC guidance: when an embargo becomes "moot"

CISA's page points readers to the CERT Guide to Coordinated Vulnerability Disclosure from Carnegie Mellon's Software Engineering Institute. It is guidance, not regulation, but it addresses the exact situations in this case.

On leaks, the guide's page on intentional or accidental leaks says:

  • "mere knowledge that a vulnerability exists in a certain component can sometimes be enough to enable a determined individual or organization to find it."
  • A partial leak "should at least trigger additional consideration of accelerating the disclosure timeline."
  • When information about a vulnerability appears in public before the vendor's date, "the embargo is effectively moot."
  • "The CERT/CC does not recommend punitive measures be taken against perceived 'leakers'."

On exploitation, the guide's page on active exploitation says evidence of exploitation in the wild "is usually a strong indication to accelerate the disclosure timeline," and that in that case too "the embargo is effectively moot." It adds that vendors, coordinators and reporters "should always be ready to immediately terminate an embargo."

On independent discovery, the guide's page on the topic warns that "An announcement of interesting vulnerabilities in a product can spur others to turn their attention and tools to that product." It recommends that participants decide "on a case-by-case basis" rather than follow a single rule.

Lorenc's account to The Register matches that last scenario. He said Chainguard learned "something was coming in PHP" from one of the researchers, then found the same bugs with its AI harness and a frontier model, and that "Just being told there's a vulnerability in a piece of software... is enough to find it."

ISO/IEC 29147 and 30111: voluntary vendor standards

Two international standards describe the vendor side of the process. The full texts are sold by ISO, so this section relies only on ISO's published abstracts.

  • ISO/IEC 29147:2018 "provides requirements and recommendations to vendors on the disclosure of vulnerabilities in products and services." The abstract says coordinated disclosure "is especially important when multiple vendors are affected," and that the standard "is applicable to vendors who choose to practice vulnerability disclosure."
  • ISO/IEC 30111:2019 "provides requirements and recommendations for how to process and remediate reported potential vulnerabilities in a product or service."

Neither abstract mentions AI. ISO lists 30111 as "to be revised."

The EU Cyber Resilience Act: reporting duties, not release dates

The CRA (Regulation (EU) 2024/2847) is binding law for products with digital elements sold in the EU. Under Article 71, most of the regulation applies from December 11, 2027, but Article 14, the reporting article, has applied since September 11, 2026.

According to the European Commission, manufacturers must now report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. Article 14 sets three deadlines for an actively exploited vulnerability:

  1. An early warning within 24 hours of the manufacturer becoming aware of it.
  2. A vulnerability notification within 72 hours.
  3. A final report no later than 14 days after a corrective or mitigating measure is available.

ENISA's FAQ defines actively exploited vulnerabilities as those "for which there is reliable evidence that they have been exploited by a malicious actor." The Commission says that "in exceptional circumstances and based on justified cybersecurity-related grounds," a national CSIRT may delay passing a notification to other CSIRTs, under a delegated act adopted on December 11, 2025.

Two other CRA provisions touch open source:

  • Article 13(6) requires manufacturers that identify a vulnerability in an integrated component, "including in an open source-component," to report it to the person or entity maintaining that component, and to share any fix they develop "where appropriate in a machine-readable format." Article 13 falls under the general application date of December 11, 2027.
  • Article 24(3) applies the Article 14(1) reporting duty to "open-source software stewards" to the extent they are involved in development. The Commission says this applies from December 11, 2027.

These duties run to authorities and maintainers. The articles reviewed here contain no rule on when a manufacturer may ship a fix to the public, and no separate rule for vulnerabilities found by AI. The sources do not say whether any company in the PHP2Shell case had a CRA reporting duty, and this post does not assess that.

Early-release triggers in four disclosure policies

Four documents, one shared trigger

The four written policies and guides in this case agree on the main reason to end an embargo early. They differ on who decides.

  • PHP project (pre-announcement, October 20): may release earlier "if details of either vulnerability become public, or if we see evidence of active exploitation in the wild."
  • Chainguard (Coordinated Vulnerability Handling Policy, updated September 22, 2026): "reserves the right to shorten the public disclosure timelines" if a vulnerability "is discovered to be under active exploitation," if details "are already publicly known through other channels," in other exceptional situations, or as required by law. It says Chainguard "will notify the reporter of any changes to the disclosure timeline."
  • OpenAI (proposed framework, October 21): teams would "reassess the timeline if there's active exploitation in the wild, a leak, a revealing public patch, or increased risk to users from stalled remediation."
  • CERT/CC guide: a public leak or evidence of active exploitation makes the embargo "effectively moot."

All four documents name active exploitation as a trigger. The disagreement in the sources is about the facts at 07:41 UTC on October 21, not about the rule:

  • Lorenc told The Register that "People were getting hit in advance." The Register also reports that before he decided to ship, "other security vendors reported seeing real-world exploitation."
  • The PHP Foundation says its security team "did not identify any functional exploits at the time of release/public disclosure."
  • CISA said it had not observed exploitation "as of the time of publication" of its October 21 alert.
  • Cloudflare says the vulnerability "was leaked before the official release date and we observed attack traffic targeting our customers." Its post does not give the time of the first attack traffic.

A second difference is the decision-maker. PHP's notice, signed by the PHP security team, says "We reserve the right to release earlier." Chainguard's policy reserves a right for Chainguard to shorten its own timelines, with notice to the reporter.

What AI changes, according to the sources

None of the official documents reviewed here has a separate track for AI-found bugs. The sources point to three pressures instead.

Volume. The PHP Foundation says its team has published 15 CVEs since July 1 and "worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible." OpenAI says it expects "similar findings to increase sharply in the coming months." The UK NCSC's chief technology officer wrote in May that AI, "when used by sufficiently-skilled and knowledgeable individuals, is showing the ability to exploit this technical debt at scale and at pace," and told organizations to prepare for a "patch wave".

Rediscovery. CERT/CC already treats a hint that a bug exists as a possible leak. Lorenc says he found the PHP bugs with an AI harness the same night he heard about them. He told The Register: "People are able to build an exploit in hours without even knowing what the vulnerability is."

Windows. OpenAI says time for distributors and providers to prepare "may be in short supply if frontier capabilities are not too far ahead of those that are broadly available." It is asking the security community for comments on disclosure windows, early notice and emergency patching, including "What evidence should trigger earlier disclosure."

For earlier background on AI and exploit timelines, see our post on autonomous coding agents compressing exploit timelines.

EU Cyber Resilience Act reporting timeline for actively exploited vulnerabilities

What to watch

  • OpenAI's consultation. OpenAI has asked for feedback on its framework, including what evidence should trigger earlier disclosure.
  • PHP's process changes. The foundation says it is changing processes "so that decisions can be made by majority" and so that hard cases reach leadership sooner.
  • CRA dates. Reporting duties for manufacturers apply now. Duties for open-source stewards and the rest of the regulation, including Article 13, apply from December 11, 2027.
  • CISA's KEV catalog. CISA's CVD process includes a Known Exploited Vulnerabilities evaluation step. As of its October 21 alert, CISA had not observed exploitation.

For the EU's separate rules on AI systems, see our EU AI Act explainer. For incident practices that US agencies published for AI developers, see NIST, NSA and CISA's ten practices.

Sources

PolicyCybersecurityExplainers

Written by

axc
axc

1,251 articles

Edited by the llms.blog desk.

More in Cybersecurity

All Cybersecurity →

Popular this week