Hell in a PHP2Shell: How AI has shrunk the patch window from days to hours

What is it about this time of year that invites a widespread, insidious cyber incident, just before the holidays? Just when security professionals had stopped getting Log4J/Log4Shell night terrors, here comes a range of critical PHP flaws that are causing mass disruption.

On 21 October, hundreds of websites were taken offline, not by attackers with exploits, but proactively by governments, companies, and organizations to prevent those websites from being exploited while their technical teams reviewed and applied patches. The cause was two critical flaws in PHP, the language behind an estimated 70% of websites. Known together as PHP2Shell, CVE-2026-109618 and CVE-2026-109619 could allow an unauthenticated attacker to achieve Remote Code Execution (RCE) on a server under the right conditions.

The bugs themselves are in the underlying C of PHP, and while it is fascinating to dig into the technical details of this incident, the bigger story here is this Out of Memory (OOM) bug isn't new: it was first raised in 2004, then again in 2019, and again in 2024. And the biggest story is arguably why, in the summer of 2026, after not being prioritized for 12 years, suddenly this same OOM bug becomes the top priority for the entire PHP Foundation security team.

So, what happened? AI models happened.

AI has shrunk the window between finding a bug and exploiting a bug

These bugs are not trivial to exploit. Chaining these flaws into a working attack vector requires a deep understanding of how PHP allocates and reuses memory across requests. Seasoned security researchers know that often the hardest part of the job is proving impact: a bug that can't be reached can't be exploited, and a bug that can't be exploited can't generate enough urgency to make a fix happen, in a world where tech teams have limited resources and backlogs that are already too long.

These bugs sat unaddressed for so long because no one could figure out how to exploit them. And because the fix was complex and required serious tradeoffs between backward compatibility, Denial of Service (DoS) potential, and impossible-to-coordinate third-party extension changes, efforts to fix the bug in 2024 stalled. This scenario will feel familiar to any team triaging security findings: a theoretical issue with an expensive fix tends to lose to issues with clear, proven impact.

Until this summer, when the PHP project was added to OpenAI's Patch the Planet program. New rounds of AI-aided security audits on PHP not only exposed the bugs, it also created the working exploit proof-of-concepts that were needed to get the fixes prioritized. Calif's timeline shows less than 2 weeks from when they found a path to the bug, to when they passed a working Proof of Concept (PoC) to the PHP Foundation. And in their write up, Wiz calls out what made the difference explicitly: "with frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work."

What this vulnerability looks like, in a nutshell

When a PHP request runs out of memory, PHP stops the request immediately. This abrupt stop means a memory cleanup step is skipped, creating a Use After Free memory corruption vulnerability. At exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory, or leave an internal state pointing to memory from a previous request.

Turning these two bugs into a working attack was complex. It required:

• Forcing an out-of-memory error at an exact point, using a small request with deeply nested form fields that makes PHP allocate far more memory than the request size (Calif)
• Arranging for attacker-controlled data to land in the freed memory, so PHP reads it as its own internal structures (Calif)
• In some chains, using a second flaw to leak memory contents and work out where things are, which defeats address randomization (Wiz)

If you want to wrap your head around the technical details of this exploit, visit our public PHP2Shell walkthrough that steps through how this one works: [PLAY NOW]

A new world: watching exploit attempts in real time

If only it were just the security researchers and technical teams being aided by AI. The PHP2Shell incident is the first time we can really see the step change in how fast attackers can turn disclosures and patches into exploits. Because organizations like AWS and Cloudflare were informed in advance, they were able to watch for exploit attempts in the wild across their customer base. And since PHP can be identified in use on an estimated 70% of websites, the attack surface of PHP2Shell is vast.

• Cloudflare saw thousands of attempts to exploit PHP2Shell in the 10 hours before it was publicly announced. In less than 24 hours after the announcement, they were tracking millions of exploit attempts.
• Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to 17 October, four days before the public disclosure. Within hours of the patch being released, AWS confirmed seeing "broad exploitation attempts in the wild".

This indicates that teams can no longer count on patch and mitigation timelines of 30 days, or even 7 days. For critical vulnerabilities, the use of AI has shrunk those timelines to hours.

The takeaways

For technical and security teams, two assumptions need revisiting.

First: "no known exploit" is weaker reassurance than it used to be, because AI tools have dramatically lowered the cost of building one. Old findings marked theoretical deserve a second look now. Code has become cheap, and that results in exploits becoming cheap too.

Second: a fix measured in weeks now competes with attacks measured in hours, which changes the ROI calculation. Proactive prevention is swiftly becoming the single best risk mitigation. If your team has applications sitting on old versions of PHP that don't have patches, you could be facing serious challenges when it comes to updating. Your technical debt has just become a critical security problem, and we should all expect that trajectory to continue as AI-enabled attackers become more capable.

With PHP essentially underpinning much of the internet’s server infrastructure, the patch rollout is expected to be quite a mammoth task. Added to the fact that it’s not just web applications that are affected (that means appliances, and essentially any internet-facing systems and products could be caught up in it too), this has the hallmarks of an ongoing headache for security personnel. It is imperative that teams are alert and prepared to not just navigate known critical exploits, but act with a security-first mindset in all aspects of software creation, whether human or AI-generated.

[PLAY THE CHALLENGE]

[SPEAK TO AN EXPERT]