This week, plenty of websites went offline as a precaution, Finnish government services and the Dutch parliament among them (The Register). The reason was two critical flaws in PHP itself, the language behind about 70% of websites whose server-side language can be identified. Fixes came out on 21 October. If you run PHP, the PHP security team and the NCSC have the steps, and they'll keep them current.

Plenty has been written about patching. Two things interest me more: how fast everything moved once the bugs were known, and how little the attack leaves behind.

Finding got cheap

The first bug wasn't new. The PHP Foundation says its root cause was spotted in 2024, but nobody had found a concrete way to exploit it, and work on a fix stalled. That changed this summer. Calif and OpenAI independently reported a working remote code execution on 11 August, and Wiz added further routes on 24 August. Wiz's researchers say frontier AI models were what turned a long-standing flaw into a working exploit (Help Net Security).

The flip side is volume. The Foundation says the PHP security team has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce.

The embargo didn't hold

Coordinated disclosure is meant to put the fix in everyone's hands at the same moment. This one leaked in stages. The PHP Foundation says the two CVE numbers began circulating online at about 15:00 UTC on 20 October, with the wrong release date and a wrong severity score, but no technical detail. That evening Calif, one of the firms that reported the bugs, mistakenly published a video of its proof of concept, then deleted it; copies spread anyway.

Then, at 07:41 UTC on 21 October, more than six hours before the coordinated release, Chainguard published built images containing the fix. The Foundation's point is that anyone could then study the fix in binary form while everyone else was still waiting for it.

Exploiting got cheap too

Amazon says proof-of-concept exploits appeared within hours of the patch, and its honeypots had already logged an attempt on 17 October, four days before disclosure (Amazon). Its explanation is that AI-assisted analysis makes it cheaper to turn a patch or an advisory into a working exploit, so more people can do it, sooner. Its conclusion for security leaders: "A 7-day or 30-day SLA assumes a delay that no longer exists."

The scale showed quickly. Pantheon, a website hosting platform, says it blocked more than 60,000 suspicious requests probing the flaws, and Cloudflare says attackers were changing their payloads to try to slip past its protections (via The Hacker News).

What it leaves behind

The attack PHP demonstrated runs before WordPress, Drupal or any other application has even loaded. CrowdStrike says the server carries on as normal, the visitor gets an ordinary page back, and the only trace may be a single memory-limit error in the web server's error log (via The Hacker News). That's the kind of line most of us scroll past as noise. Application logs and security plugins see nothing, because no application code ever ran.

CrowdStrike also points out that the exposure doesn't depend on the CMS, framework or plugins in use, and The Hacker News notes that any reachable PHP endpoint is in play, down to a login page or a health check. There's no clever entry point to look for in the logs, because every page is one.

PHP's own advisory says as much: an empty error log is not proof that nothing happened.

Then the fix tidies away some of what's left. Patching means restarting every PHP worker, which is exactly right, and also clears whatever was in memory. Rebuilding a server overwrites file timestamps. CDN and firewall logs on hosted plans can be kept for only days.

The second flaw adds a twist. PHP lists memory disclosure as a confirmed impact, so a server with no backdoor on it may still have given away its database password.

That early attempt matters for anyone looking back. Amazon suggests investigating from at least 17 October, not from disclosure. Logs that only go back to Tuesday miss it.

Why this is an eDiscovery problem too

In my world, a log file is a document. If anything comes of this later, a dispute with a host, a supplier or a client, those few lines in an error log are the evidence. Court rules such as Practice Direction 57AD expect relevant documents to be preserved, including ones a third party holds for you (Bristows).

Here, those third parties are your host and your CDN. Their retention settings are working through the logs right now, on their own schedule, whatever is going on with you.

There's a step before that, though. VulnCheck counts PHP on about 2.6 million internet-facing hosts, and over 700,000 of them run versions with no official fix (via The Hacker News). PHP no longer supports 8.1 and earlier, and the NCSC warns that PHP is bundled inside other products and appliances, often without saying so.

In eDiscovery terms, that's a data mapping problem. Before anyone can preserve the logs, someone has to know which systems run PHP, who hosts them and where their logs go. The organisations that can answer that quickly this week will be the ones that had already mapped it.

Where I land

AI has made finding and exploiting bugs faster. It hasn't made deciding any faster. The PHP Foundation is candid that its fix stalled for months over trade-offs only experienced engineers could weigh, and calls the delay a structural failure. Tools can find the bug; people still have to choose the fix and review it.

The Foundation's numbers make the same point from the other side. More than 100 reports that went nowhere is a lot of skilled human time spent sorting what the tools surfaced. Faster finding didn't reduce the work; it moved it.

Legal tech is living through the same shift. AI is making the finding part of our work cheaper: surfacing documents, spotting patterns, flagging issues. The deciding part, what's relevant, what's privileged, what goes out of the door, still needs experienced people and time.

Anyone who has run technology-assisted review will recognise the pattern. The tools surface more, faster, and the human workload shifts rather than disappears. PHP2Shell is the same lesson in a different setting.

One practical point for anyone buying legal tech: if a supplier's contract gives it weeks to patch a critical flaw, it's pricing in a delay Amazon says attackers no longer allow.

And the evidence doesn't speed up at all. Patch first, no argument. But copying the logs off the box takes minutes, and it's the difference between thinking you're fine and being able to show it.

The Forted Bunker looks at this from a legal tech and digital evidence standpoint. Nothing here is legal advice. Facts as of 22 October 2026.

Sources
PHP security advisory, 21 October 2026
GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
PHP Foundation: Today’s PHP security release
NCSC: Critical security issue affecting PHP
Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
The Hacker News: Someone tried to exploit PHP2Shell four days before disclosure (CrowdStrike and VulnCheck figures)
Help Net Security: PHP2Shell patched (Wiz researchers’ comment)
The Register: PHP devs publish critical bug fix
Practice Direction 57AD
Bristows on legal holds
W3Techs: PHP usage statistics

#FromTheBunker #RolfBerryman #APTSearch #eDiscovery #CyberSecurity #DigitalForensics #LegalTech #FTE #Forted  #DFIR #Cyber #TheFortedBunker