This week PHP shipped fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They allow unauthenticated remote code execution, they affect almost every PHP version back to 5.4, and Wiz showed them working against WordPress and Drupal. If you run PHP, patch first and read later.
What caught my attention is the coverage. A good part of it framed this as a race to patch before “AI-powered hackers” arrive. I went through the advisories and the write-ups from the people involved, and I don’t think the evidence supports that story.
The bug is older than the hype
Calif’s write-up says the earliest affected code path dates to PHP 5.4.0, released in 2012. The bug class is even older. Calif traces the idea back to Stefan Esser’s memory-limit RCE in 2004, a related out-of-memory report to PHP in 2020, and a 2024 audit by OSTIF and Quarkslab that found a similar issue but couldn’t prove it was exploitable, so it wasn’t fixed.
The PHP advisory describes the main bug plainly. When PHP runs out of memory halfway through setting up a request, it bails out and leaves state half-initialised, and the cleanup code then trusts that state. That’s a classic C memory-safety problem. Nobody’s model wrote it.
AI was on the defenders’ side
Where AI shows up in this story, it’s with the people who found and fixed the bug. Calif’s researcher started from his own knowledge of PHP’s history and used an LLM as an “audit buddy” to chase allocation paths. Wiz used Gemini 4 Argon and GPT-5.6 Sol to turn the bugs into exploits, a chain it describes as “at the edge of what human researchers could practically achieve”. The PHP Foundation credits Calif, Wiz and OpenAI, and says it uses AI tools to validate reports, but “a person makes every call and works on every patch”.
No evidence the attackers used AI
I couldn’t find any. Amazon saw a first exploitation attempt on its MadPot honeypots on 17 October, four days before disclosure, and says it is unclear how the actor got the exploit information. The PHP Foundation describes a messy embargo: CVE identifiers circulating on 20 October, Calif accidentally publishing a video of its proof of concept, and a vendor shipping fixed images six hours early. Public proofs of concept appeared within hours and were used against Amazon’s sensors almost immediately.
That’s a leak followed by mass exploitation, which is what happens to big bugs. Neither Amazon nor the PHP Foundation says the attackers used AI.
Where AI does matter
I don’t want to swing too far the other way. Amazon makes the fair point that AI-assisted analysis makes it cheaper to turn a patch diff or an advisory into a working exploit. If a model can help a researcher build a reliable RCE across PHP versions in hours, it can do the same for someone with worse intentions.
That is acceleration, not causation. AI is shrinking the time between “the bug is public” and “the bug is exploited”. It didn’t create this bug, and here it’s a big part of why the good guys found it first.
What I’d take from it
The boring parts of this story matter more than the AI part. A 2024 audit came close to this bug and it stayed open because nobody could prove exploitation. PHP 8.1 and earlier won’t get a fix. Self-built container images won’t update themselves. Amazon’s advice is to measure patch timelines for critical internet-facing bugs in hours, not days, and to start investigations from 17 October rather than the disclosure date.
So blaming AI misses the point. The useful lesson is that the window between disclosure and exploitation keeps shrinking, and most organisations still patch as if it didn’t.
Sources: Calif — PHP2Shell technical write-up, Wiz — PHP2Shell: AI uncovers critical RCE vulnerabilities, PHP — GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), PHP — GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), The PHP Foundation — Today’s PHP security release and how we’re strengthening PHP security, AWS — Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, Google Cloud — Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
Opinions are my own.