PHP2Shell, found by AI

PHP2Shell is two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 and both exploitable without logging in. What makes them unusual is where they live. They're in PHP's core engine rather than in any framework or application, so according to Wiz even a "Hello World" script on an affected version can be vulnerable, and every PHP version released in the last decade is affected by at least one of them. Given how much of the web still runs on PHP, from WordPress sites to the Yii, Laravel and other PHP applications we look after, that's a lot of servers.

From a bit of reading, the bugs themselves aren't new. They're memory-safety problems in how PHP tidies up after a fatal error, an out-of-memory error in particular, which can leave a dangling pointer behind for the next request handled by the same worker to trip over. That code has been sitting there for years. What changed is that two teams went looking with AI. Calif used OpenAI's GPT-5.6 Sol, and Wiz Research, working independently, used Gemini 4 Argon and GPT-5.6 Sol alongside its own Wiz Atlas tooling. Both arrived at the same flaws.

AI also helped with the exploit itself. Turning a memory bug like that into working remote code execution takes what Wiz call "an exceptionally complex chain of steps", and that's usually been the barrier that keeps bugs like this theoretical. Wiz say the models helped build the chain against WordPress, Drupal and Joomla, then adapted it to different PHP versions and memory layouts, iterating on each test failure, in hours. That's exactly the kind of patient, repetitive work a person would probably give up on, or would take long enough over that the flaw would be patched before their exploit reached very far. It's also exactly the kind of work AI is very happy to keep on going with, relentlessly.

Finding PHP2Shell needed thoroughness more than anything: someone had to read a lot of old, complicated code very carefully, and then keep trying combinations until one worked. People are capable of that, but we get tired, we get bored, and we have other things to do on a Wednesday afternoon. An AI model, if you ask it to, will keep going through every code path, every version and every failed attempt without losing interest.

Patching PHP2Shell for our clients

On the morning of the 21st, before there was a patch to install, the first thing we did was let our clients know - what the issue was, that we were monitoring it, and that we were preparing for the fixes. Then we gathered a list of every affected service, documented it in our knowledge OS, and split it into groups that would be handled differently: applications running on Elastic Beanstalk on one side, containerised apps on ECS on the other.

PHP released the fixes at 2:45pm. From there it was a case of pushing out the recommended mitigations and WAF rules, then following the upstream image builds from Docker, Yii and Amazon Linux as they landed. Throughout, we kept a log for every service of what we did and when, with Claude acting as orchestrator and note-taker - it's useful having an extra pair of hands writing things down while you're focused on the patching itself. By 8am the following morning every one of our supported clients was patched.

None of that felt like an emergency, mostly because our supported clients' applications get regular updates anyway, so the development machines and deployment workflows we used are ones we use all the time, and shipping an update wasn't anything new. It also meant none of our clients were on an old version of PHP. That mattered more than usual this time, because official releases only exist for PHP 8.2 and later, and Bitsight found only about a third of the PHP installs they could identify were on a branch the update covers, with PHP 7.4, which PHP itself stopped supporting in 2022, the most common by far. It's the case for retained support and maintenance: when something like this lands, you want to be patched overnight rather than finding out your PHP version doesn't get a release at all.

A new era of AI-discovered software vulnerabilities?

I don't know, but I suspect so, at least for a while. There's a lot of old code underpinning the web that has never had this kind of attention, and if two teams can find bugs like PHP2Shell in something as widely used and widely read as PHP, it seems likely there are more to come in places that get far less scrutiny. My guess is we'll see a run of more frequent, more serious disclosures until the same tools start catching these problems before the code ships in the first place.

Some of those will be what security people call zero days: flaws that attackers find and use before the people who maintain the software know they exist, leaving them zero days to fix it. PHP2Shell wasn't one of those, because the researchers reported what they found and the fix was released alongside the announcement, which is how it's meant to work. The worry is that the same AI tools are just as available to people who won't report what they find.

Coincidentally, the same week brought a reminder of what can slip through when the routine checks aren't happening. eMudhra, one of the companies that issue the certificates behind the padlock in your browser, turned out to have certificates whose private keys anyone could have guessed in at most 256 attempts, and they'd been like that for about 17 months until a researcher running a simple check spotted it. There was nothing clever about it, but it's exactly the sort of check AI could keep running for you every week, rather than whenever somebody remembers.

In the meantime the practical answer is fairly unexciting: keep things up to date, know what you're running and where, and have the people and processes in place to move quickly when the next one lands. That's what made this week manageable for us. I'd be interested to hear how others handled it, and if you're not sure your applications would have been patched by 8am the next morning, get in touch and we can talk it through.