PHP2Shell: the embargo lost to the clock

The PHP Foundation's postmortem on CVE-2026-109618 and CVE-2026-109619 is worth reading in full. It is honest about what went wrong, and most of what went wrong was not anyone's fault. The embargo did not break because someone was careless. It broke because the thing it was protecting had stopped being a secret the moment it was found.

The timeline, compressed

The bugs are memory-management flaws in the PHP runtime itself: an allocation that trips memory_limit or another fatal error interrupts native code before cleanup, request-owned state survives into shutdown, and the next request can reach it. Calif's Ryan Austin found them with GPT-5.6 Sol. Wiz found overlapping issues independently. Calif confirmed pre-auth remote code execution against default installs of WordPress, Drupal, Joomla, Nextcloud, Laravel and half a dozen more. The earliest affected path dates to PHP 5.4.0, released in 2012.

Then the schedule fell apart.

• Oct 17. Amazon's MadPot honeypots log an exploitation attempt from an anonymising network. Four days before release, while the bugs were still under embargo.
• Oct 16, evening. Chainguard learns a PHP disclosure is coming and, by Dan Lorenc's account, re-finds the vulnerability that night with an in-house AI harness and a frontier model. It is formally added to the coordination channel the next day.
• Oct 20, ~15:00 UTC. The CVE IDs appear on forums with a wrong release time and a wrong CVSS of 10.0. No technical detail, but enough for everyone to start hunting. watchTowr reproduces CVE-2026-109618 the same day.
• Oct 20, ~20:00 UTC. Calif accidentally publishes a demo video. Deleted; copies circulate.
• Oct 21, 03:59 UTC. Fastly sees the first request from a tool with PHP2Shell in its name. By release, more than 100 source IPs had used tooling under two dozen names, one with the CVE number in its User-Agent.
• Oct 21, 07:41 UTC. Chainguard publishes patched images, six hours early, citing exploitation in the wild. The Foundation calls it a unilateral break. Lorenc says he regrets the stress and would make the same call.
• Oct 21, 14:00 UTC. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship, a day earlier than planned.

What actually changed

Every argument in that thread, Chainguard versus the Foundation, early patch versus orderly release, is a reasonable argument about the old world. In the old world a critical bug in a runtime used by most of the web was known to a handful of people, and the window between private fix and public release was a safe place to package updates.

What PHP2Shell shows is that the window is no longer safe, because finding the bug is no longer the hard part. One team found it on purpose. A second found it independently. A third re-found it in an evening once it knew where to look. Someone we do not know about had a working exploit on Oct 17. The leak on Oct 20 contained no technical detail at all, and that was still enough.

The embargo protected a fact that three teams had already derived and a fourth was already using.

That is not a disclosure-process problem. Art Manion at FIRST made the same point in the aftermath: co-discovery is now the default assumption, not the edge case. A process built on scarcity has to be rebuilt for abundance.

For the people on the defending side

Two things follow from this, and neither is comfortable.

First, the vendor's release time is no longer your deadline. The honest deadline is "when someone with a harness decides to look", and for anything exposed to the internet that is measured in hours from the first rumour. Fastly's telemetry had tools scanning nine hours before the fix was public. If your plan was to patch during the maintenance window after the advisory, you were already late.

Second, the same capability that compressed this timeline is available to you. Chainguard did not have a zero-day in its back pocket. It had a model, a harness and a hint, and that was enough to go from "something in PHP memory handling" to a working reproduction overnight. We see the same thing running our own agents against customer code: the finding is rarely the expensive step any more. Proving it, fixing it, and getting the fix out ahead of the people who found it alongside you — that is where the time goes now.

PHP did not become more vulnerable in October. The bugs were there for fourteen years. What changed is the clock.

Sources: the PHP Foundation's Oct 21 postmortem (as reported by Socket), Calif's PHP2Shell writeup, the AWS Security Blog on MadPot telemetry, Fastly's timeline and WAF data, and TechTarget's interview with Dan Lorenc.