PHP's RCE embargo leaked: what the Foundation says went wrong

The two critical PHP bugs we reported on October 21 had a messier disclosure than the release suggested. The PHP Foundation has published its own account: identifiers leaked a day and a half early, a proof-of-concept video got out, and a distributor shipped the fix hours before the agreed time. It also admits the underlying fix sat stalled for months. We read the Foundation’s post in full and a secondary report on the dispute. This article covers what the Foundation says happened, what Chainguard is reported to have said, what it says about AI-assisted research and what remains open. Our earlier PHP article has the affected versions and mitigations, which this one does not repeat.

Why was the fix so slow, according to the Foundation?

Because the decision was hard and the team was small. The Foundation says the first signs of the memory-limit (OOM) problem behind CVE-2026-109618 appeared in 2024, while fixing an issue from the first external PHP security audit in years. That audit was done by Quarkslab, organized through OSTIF and funded by Germany’s Sovereign Tech Agency. A potential exploit was theorized then, but no concrete vector was found and other issues overshadowed it. The security team developed several competing fixes, each with a cost: broken backward compatibility, new denial-of-service potential, or changes to many third-party extensions. Operating on consensus, it struggled to choose, and the work “stall[ed] and restart[ed] repeatedly over months”. The Foundation writes that the delay “was a structural failure”, caused by the decision process and a lack of resources, and says the team is changing its processes so decisions can be made by majority.

What happened to the embargo?

By the Foundation’s timeline (all UTC), it unravelled in stages:

• October 20, about 15:00: the two CVE IDs start circulating on forums and social media with a wrong release time and a wrong CVSS score of 10.0, where the real one is 9.2. No technical details leaked.
• October 20, 19:30: the project publishes its pre-announcement early and moves the release from October 22, 14:00 to October 21, 14:00. Distributors were still packaging the fix, so the Foundation says one day earlier was the best compromise.
• October 20, about 20:00: after the pre-announcement, Calif, one of the firms that reported the bugs, mistakenly publishes a video of its proof of concept working against several targets. It was deleted, but copies circulated and, the Foundation says, sped up work on other PoCs.
• October 20, about 23:00: mitigation advice given to a few critical infrastructure providers “may have leaked as well”.
• October 21, 07:41: Chainguard publishes built images containing the fix, more than six hours before the release. The Foundation says it “unilaterally broke the embargo” and let any attacker study the fix in binary form while other users waited.
• October 21, 14:00: release. The Foundation says its team inspected the PoCs that appeared after the leak and found no functional exploit at release time.

What does Chainguard say?

Per a secondary report, that it acted because exploits had appeared. Socket reports that Chainguard’s CEO, Dan Lorenc, wrote in a Hacker News comment that he made the call to release early “when exploits hit in the wild”, cited how easy the bug was to discover and information already circulating, said the images were free and tested, and that other vendors in the disclosure had reported exploits in the wild by Tuesday night without naming them. Socket also says he defended the decision on LinkedIn and apologized for the added stress on PHP’s maintainers. We did not read his comment or post, and we found no Chainguard statement beyond Socket’s account. The Foundation’s claim is narrower: it says its own inspection found no functional exploit at release time. Socket also reports that Cloudflare’s Dane Knecht said it saw early attacks before the patches arrived and deployed temporary WAF protections, which Socket notes does not show any server was compromised.

What does the Foundation say about AI and the reports?

That AI raises the volume and people still decide. It says it scanned PHP earlier this year with Anthropic’s Claude Mythos, with Alpha-Omega, and has since added tools such as OpenAI’s Daybreak Red for validating reports and exploits. It joined the Patch the Planet program, in which Calif began an audit on July 30. The Foundation says that on August 11 Calif researcher Ryan A reported an unconditional remote code execution with the same root cause as the 2024 OOM problem, that OpenAI independently reported the same root cause and sent more attack vectors on September 18, and that Wiz sent vectors on August 24. From August 11 fixing it became top priority. Since July 1 the team has published 15 CVEs and handled more than 100 reports that were invalid, duplicates or not reproducible. AI helps validate and group reports, the Foundation says, but a person makes every call and writes every patch.

The sources differ on dates. Socket cites Calif’s own timeline as showing a PoC shared with PHP on August 14 and confirmed on August 15, a few days after the Foundation’s August 11 report date. Wiz’s post, which we cited earlier, says PHP acknowledged its report on September 21. We cannot tell whether these describe different steps of the same process.

What does the Foundation ask for?

Money, from the organizations that depend on PHP. It says tools find bugs faster than ever, for defenders and attackers alike, but cannot decide the right fix for a long-standing design decision, and few engineers know the whole engine. It asks companies building on PHP, hosting providers, cloud platforms and distributions, and governments to sponsor it, pointing to the Sovereign Tech Agency’s 2024 audit funding as an example. It names no amounts or deadlines, and its commitments on process are described in general terms.

What is still unknown?

• Who first leaked the identifiers on October 20. The Foundation does not say.
• Whether exploits were really in the wild before the release. Chainguard’s reported claim and the Foundation’s finding differ, and neither is independently documented in what we read.
• How the process changes will work in practice, since the Foundation gives no dates.
• Whether other reports will surface from the same root cause. Wiz’s earlier post said further variants exist.

What to keep in mind

These are our observations:

• The slow fix was a people problem, not a tooling one. The Foundation’s own account puts the delay on decision-making and staffing, while AI found the bugs faster than a small team could settle on a fix.
• An embargo breaks in stages, and each stage shortens the window. By the Foundation’s timeline the identifiers were public about a day before Chainguard published, so the dispute concerns the last six hours of a window that had already narrowed.
• The two accounts of exploitation conflict. Treat claims that exploits were in the wild as unverified, and the Foundation’s “no functional exploits at release” as its own inspection.
• Patching still comes first. If you have not updated since October 21, our earlier article lists the versions and interim mitigations.

Editorial review: October 23, 2026 (AI). Prepared from The PHP Foundation’s post of October 21, 2026 (read in full as page text) and Socket’s October 21 report on the dispute (read through a summarizing fetch). We did not read Chainguard’s Hacker News comment or LinkedIn post, Calif’s own timeline or statement, or php.net’s announcement, and we did not contact the Foundation, Chainguard or Calif. A Hacker News post by an individual who said they had shared the upcoming CVEs without knowing of an embargo was not used, because we cannot verify it is the origin the Foundation describes. Details may have changed after our reading.