PHP2Shell: The Patch Gave Attackers Their Roadmap
Two critical PHP flaws drew millions of exploit attempts within hours of disclosure. The bugs were serious. The breakdown in coordinated disclosure was worse.
Key points
- Chainguard published a container image containing the PHP fix roughly six hours before the agreed embargo lifted on October 21, 2026, giving attackers a working patch to reverse-engineer while most PHP users were still unprotected.
- Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 on the severity scale, allow attackers to run any code they choose on a vulnerable server.
- AWS reported at least one exploit attempt on October 17, four days before the public patch, originating from an anonymisation network.
- Cloudflare saw thousands of attacks ten hours before the public announcement, rising to millions within two hours of the patch going live.
- Some government websites went offline entirely rather than risk exposure while waiting for an update.
PHP is the programming language that quietly powers a large share of the web. Content management systems, e-commerce stores, government portals: enormous amounts of the internet run on it. When two critical flaws surfaced in October 2026, every one of those sites became a potential target.
The pair of vulnerabilities, collectively dubbed PHP2Shell, were published on October 21, 2026. Both carry a severity score of 9.2 out of 10. Our earlier story on the day the patches landed found that the flaws sit in the language itself, not in the applications built on top of it.
CVE-2026-109618 exploits the way PHP handles running out of memory. When memory runs short, PHP uses a technical escape hatch called longjmp() to abandon the current request. Some parts of the system don't clean up properly before doing so, leaving memory in an uninitialised state. A subsequent request can then read or act on that leftover memory, giving an attacker a reliable path to remote code execution, meaning the ability to run any command on the target server from anywhere on the internet.
CVE-2026-109619 works differently but lands in the same place. PHP keeps certain global settings that temporarily point into the memory space of whichever request is being handled. If those settings aren't properly wiped between requests, a later request may act on stale data from memory that has already been freed. Again, the result is remote code execution.
How did the disclosure fall apart?
The PHP Foundation coordinated patches with distributors, including security company Chainguard, weeks in advance, setting an embargo for October 22, 2026 at 14:00 UTC.
Things started slipping on October 20. The two CVE identifiers began circulating online around 15:00 UTC, without technical details but enough to signal something significant was coming, and the PHP project moved its pre-announcement forward to 19:30 UTC that evening.
That shift triggered a chain of errors. Cybersecurity firm Calif mistakenly published a video demonstrating a working exploit against real targets. The video was deleted, but copies had already spread across social media.
Then, at 07:41 UTC on October 21, Chainguard published built container images, which are pre-packaged software bundles that organisations deploy, containing the fix. Six hours before the agreed release time. A fix published early is, as researcher Frank Dickson of Dickson Research put it, "a treasure map": attackers can compare the patched version against the old one and work backwards to understand exactly what the flaw was and how to exploit it.
Chainguard CEO Dan Lorenc defended the move, saying his team had independently built a working exploit and seen evidence that active attacks were already underway. AWS CISO CJ Moses later confirmed at least one exploit attempt on October 17, four days before disclosure, from an IP address tied to a commercial anonymisation service.
Should organisations still be updating right now?
Yes. Official patches landed on October 21, 2026 at 14:00 UTC, twenty-four hours ahead of the original schedule.
Cloudflare's numbers illustrate the urgency. Thousands of exploitation attempts arrived ten hours before the public announcement, then tens of thousands in the forty-five minutes after patches went live, hundreds of thousands within two hours, and millions shortly after. Every unpatched PHP installation remains a live target.
| Event | Date / Time (UTC) |
|---|---|
| CVE IDs begin circulating online | Oct 20, ~15:00 |
| PHP Foundation pre-announcement | Oct 20, 19:30 |
| Chainguard publishes patched images | Oct 21, 07:41 |
| Official patches released | Oct 21, 14:00 |
| Original embargo date | Oct 22, 14:00 |
| AWS-reported earliest exploit attempt | Oct 17 |
If your site runs PHP, confirm your hosting provider or IT team has applied the October 21 patch. If you manage your own servers and haven't updated, do it now.
The disclosure story is the part that'll outlast the patch cycle. Coordinated disclosure is still the right model, but it's getting harder to run. David Shipley, CEO of Beauceron Security, noted when CSO Online covered the fallout that the more people who know about a flaw and the longer the timeline, the more likely something leaks. With AI tools now able to accelerate the analysis of partial information and produce working exploits, the window between "secret" and "widely known" is collapsing. Dickson put it plainly: shorter windows, fewer early recipients, and a shared understanding that the fix itself is the secret. The WordPress file-inclusion episode we reported on 24 September showed the same race between patch and attacker, but at least the disclosure held together. Here it didn't, and millions of exploit attempts followed.
