Sajid Shoaib
The most interesting part of the PHP2Shell story is not the severity score. It is how quickly a long-known weakness became a working attack, and what that implies for everyone who runs software they did not write.
A weakness the project had already glimpsed
According to The Hacker News, citing the PHP Foundation, a core developer saw signs of the out-of-memory flaw during PHP’s 2024 external audit, but no concrete route to code execution was found at the time. Competing fixes then stalled for months, which the Foundation itself called a structural failure. The lesson is uncomfortable: a risk that is understood in theory but not proven exploitable tends to sit in the queue.
What the researchers say AI changed
The flaws were reported by Wiz Research, Calif and OpenAI’s Codex Security team, working with the PHP security team and Google’s Gemini team on the fix. The researchers say AI models helped turn the flaws into working exploits, letting one researcher do in about a week what would otherwise take a team months. Calif also said that knowing the target’s history still mattered, and that current models do not reliably start from obscure, decades-old primitives on their own. These are the researchers’ own claims, and they cut both ways: the same speed-up is available to defenders and attackers.
A messy disclosure
The timeline shows how fragile coordination becomes when everyone is moving fast. A leak said disclosure was planned for October 22, so PHP posted an advance notice and moved the release up. Around 20:00 UTC on October 20, Calif accidentally posted a video of its proof of concept, per the PHP Foundation. Chainguard published images containing the patch about six hours before the fix shipped. By 14:19 UTC on October 21, watchTowr was reporting active exploitation attempts, and Cloudflare said attackers were changing payloads to evade the firewall rules it had switched on by default.
The part that does not change
For all the talk of AI, the practical defence is the old one. Only updating is a complete fix, according to the PHP advisory, and the first people hurt are those running unsupported versions with no patch available. PHP 8.2 reaches end of life on December 31, 2026, which means even a fully patched 8.2 site has a countdown running. If you run a site yourself, our plain-English PHP2Shell patch checklist shows what to do first.
What this means for people who build on the web
Three takeaways stand out. First, assume the gap between disclosure and exploitation is shrinking, so keep a standing process for emergency patching rather than inventing one under pressure. Second, treat end-of-life software as a liability on a schedule, not a someday problem. Third, ask your hosting provider how quickly they patch runtime flaws, because for most site owners that answer decides how exposed they are.
The researchers’ own caution is worth keeping in mind as well: these accounts come from the people who did the work, and independent analysis of how much AI really changed the picture is still to come.
If you want the practical side for client work, this guide for freelancers and agencies explains how to respond to worried clients and scope a fair security offer.
