Would an AI WAF Have Stopped php2shell? Wrong Question.
php2shell is a critical bug in the PHP runtime itself, and almost half of PHP sites run a version with no patch coming. Scared site owners are reaching for AI WAFs. Here is why that is the wrong question, and what actually keeps you from getting owned.
A new PHP bug landed this week, and it is a bad one. People are calling it php2shell. It is two flaws, CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 out of 10. Some researchers called it a full 10. Source: Help Net Security | SecurityWeek
The details leaked before the patch was ready. By October 21 attackers were hitting live sites at scale. Source: Hadrian
Here is the part that scares people. The flaw is in PHP itself, not in your code. Your app can be clean and you are still exposed. Source: The Hacker News
So I keep getting one question. Would an AI WAF have stopped this? I think that is the wrong question. Let me show you why.
What php2shell actually is
Most web bugs live in your application. A bad form field. A weak login page. php2shell is different. It lives in the PHP runtime. That is the engine that runs every PHP site. Source: Hadrian
The worst setups run mod_php with Apache. There an attacker needs no login. The bug can fire before your code even runs. PHP flags that case as the highest risk. Source: Hadrian
Most attacks so far abuse one feature. It is called session upload progress. PHP mishandles memory while it reads an upload. Source: Hadrian
Now the ugly part for defenders. The bad request can look normal. It is a file upload. There is no weird SQL quote. No script tag. No ../ in the path. There is nothing for a filter to scream at.
We have seen this movie before
This all feels familiar. It reminds me of the early days of SQL injection. A niche trick went mainstream fast. The tooling got cheap. By 2008 a botnet was mass-scanning the web for one weak field and poisoning every site it found. Source: Dark Reading (Asprox, 2008)
php2shell has the same shape. It is unauthenticated. It is in the runtime. It is trivial to scan for. So right now every actor, good and bad, is sweeping the web for vulnerable sites. With this many abandoned apps out there, they are all but guaranteed to find some.
But this is worse than SQL injection in one key way. SQL injection was a bug in your app. A maintained app could fix it in code. php2shell is a bug in the PHP runtime. On an end-of-life version, the owner has no fix at all. The abandoned app is not just unpatched. It is unpatchable.
Yes, AI speeds up both sides now. Attackers auto-generate scanners. Defenders auto-write virtual patches. But that is not a fair trade. The attacker needs one win across millions of sites. The defender has to fix every single one. Faster tools do not help a site with nobody left to run them.
This is vulnerability discovery going vertical. I wrote about that shift when an AI model surfaced thousands of zero-days at once. php2shell is one of the first effects of it, not the last.
The real problem is old PHP
PHP shipped fixes on October 21. The safe builds are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Source: Help Net Security Patch and you are safe. Simple, right?
Not for most of the web. Look at what PHP sites actually run today. These figures come from Hadrian's PHP version and fix table, built on W3Techs data. Source: Hadrian, PHP version / official-fix table (W3Techs, Oct 21 2026)
Add it up. Around 48.5% of PHP sites run a version with no official fix coming. Source: Hadrian, PHP version / official-fix table PHP runs about 69.3% of all sites with a known backend. So this is close to a third of the whole web. Source: W3Techs via Hadrian
These are end-of-life versions. Upstream stopped supporting them years ago. PHP did publish bare source patches for 7.4, 8.0, and 8.1, but you have to build from source yourself. Source: Hadrian Most site owners never will.
This is the heart of it. A huge slice of the web cannot patch. So they go looking for something to buy instead. And the market has an answer ready. It is the AI WAF.
Why "will an AI WAF save me" is the wrong question
I wrote a whole guide on what "AI-powered" really means on a WAF. Read that for the full picture. The short version is this. A real AI WAF learns your normal traffic and flags the odd stuff.
That sounds perfect for a bug no one has a rule for yet. But think about what the model sees. It sees the request. php2shell does its damage inside PHP memory, after the request is let through. The clue is not in the bytes on the wire. So the model has nothing to learn from.
Once a public exploit exists, a WAF can block the known shape of the attack. That is real and useful. But that is a signature. It is a virtual patch. A plain rules-based WAF does the same thing, often faster.
So the AI badge adds little here. The thing it is sold for, catching a brand-new attack by reading intent, is the thing it cannot do for a memory bug. Knowing which bytes break PHP comes from the CVE. It does not come from the model being clever.
What actually stops you getting owned
A WAF is a seatbelt. It is not the brakes. Here is what does the real work.
- Get off end-of-life PHP. This is the only true fix. PHP 8.2 or newer gets patches. Everything older is on borrowed time.
- Run PHP with least privilege. Use php-fpm, not mod_php. Give the worker its own low-rights user.
- Make your upload folder non-executable. If a shell lands there, it should not run. A dropped
.phpfile is useless if the server refuses to execute it. - Turn off session upload progress if you do not use it. Set it in php.ini or the FPM pool, then restart workers.
- Block stray
.phprequests. An attacker who gets in usually drops a shell and calls it. A rule that 404s unknown.phpfiles blunts that step. - Keep clean backups. An owned box stays owned. The honest fix for a breach is a restore from a known-good copy. Source: Hadrian
; php.ini or your FPM pool, then restart workers.
; Set it here, not with ini_set() or .user.ini.
; This helps, but it is not a full fix on its own.
session.upload_progress.enabled = 0Where a WAF does earn its place
I am not saying skip the WAF. A WAF buys you time. That matters a lot when you cannot patch today.
Take Nivoli Edge as an honest example. Its "PHP parser guard" blocks malformed uploads at the edge, before PHP reads them. Its own docs list CVE-2026-109618 and CVE-2026-109619 among the flaws it covers. Source: Nivoli docs
But read the next line in those same docs. The guard "reduces exposure to flaws in PHP itself" and "does not replace updating PHP". Source: Nivoli docs That is the honest framing. I wish more vendors wrote like that.
A stray-.php rule and a parser guard slow an attacker down. They do not make an unpatched runtime safe. No WAF does.
The takeaway
So, would an AI WAF have stopped php2shell? For the brand-new attack, no. For the known shape later, a signature stops it, and you do not need AI for that.
The real lesson is older and more boring. Patch what you can. If you cannot patch, harden. Least privilege. Non-exec uploads. Clean backups. Then put a WAF in front to buy time.
The box you buy is not the fix. The habits are.
