PHP2Shell: I Patched 13 Servers in Two Days, and AI Is Not the Villain Here

At this point, I think even the cavemen know about the PHP vulnerability.

If you somehow missed it: on 21 October 2026, the PHP Foundation shipped an emergency patch for two critical flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, now being called PHP2Shell. Every PHP version going back to 5.4 is affected. That is more than a decade of releases. Attackers can use these flaws to run their own code on a server remotely, in some cases without logging in to anything. PHP runs something like 70% of the websites on the internet, including WordPress and Drupal, so you can imagine how the week went for anyone who manages servers.

I work on PHP frameworks every single day. Laravel is the backbone of almost everything we build at Resonics. So this one was not a news story for me. It was a to-do list.

13 servers, two days

My company manages 13 servers. Some are our own, and some belong to clients whose websites and applications we built and still look after.

Every single one had to be patched.

On paper, "update PHP" sounds like one command. For some of the servers, it actually was. A quick apt-get update and upgrade, restart the services, test the sites, done. Those were the lucky ones.

The rest needed a full operating system upgrade first. A few servers were still on Ubuntu 20.04, and some of those had to go to 22.04 while others went all the way to 24.04.

A quick word on why that matters, for anyone who doesn't live inside servers. Ubuntu puts out a Long Term Support (LTS) release every two years, in April. That is what the "04" in 20.04, 22.04 and 24.04 means: April of 2020, 2022 and 2024. Each LTS release gets security updates for five years. That long support window is exactly why servers run on LTS versions. You set one up, it stays stable, and it keeps getting fixes for years without you having to touch it much.

The catch is that five years ends. Ubuntu 20.04's standard support ran out in 2025. A server on an older release is no longer first in line for fixes, so getting a properly patched PHP onto it meant upgrading the OS underneath it. And you cannot jump straight from 20.04 to 24.04. You go from 20.04 to 22.04, and then from 22.04 to 24.04, one release at a time.

An OS upgrade is not a small thing on a live server. It changes far more than PHP. Packages get replaced, configuration files change, and things that worked yesterday stop working today.

The worst of it was Python. Some of these servers also run Python scripts and tools alongside the PHP applications. Each Ubuntu release ships with a different Python version: 3.8 on 20.04, 3.10 on 22.04 and 3.12 on 24.04. A Python virtual environment is tied to the exact Python it was created with, so when the system Python changes, the environment underneath your app simply breaks. On top of that, 24.04 no longer lets you casually install Python packages system-wide with pip. So the Python environments had to be rebuilt from scratch, and every dependency installed and tested again.

So for each server it was: check what it is running, decide between a simple update and a full OS upgrade, do the upgrade one LTS step at a time, fix whatever broke, rebuild the Python environments, make sure PHP-FPM and the web server are running the patched version, and then confirm the application still works.

Then you check again. Because the one server you assume is fine is always the one that isn't.

It was a painful and long process. It took two whole days to make sure every version was patched. But it is done.

My clients don't even know this happened

Here is the part I find quietly satisfying. Most of my clients have no idea any of this happened. Nobody called me. Nobody asked if their website was safe. Their sites were up on Monday, and they were up on Wednesday, and in between, the hole was closed.

That is exactly how it should be. That is what they are paying me for.

When a business owner hires a company to build a website or a custom software system, the build is the visible part. The invisible part is everything that happens after launch: updates, patches, backups, monitoring, and weeks like this one where you drop everything because something underneath the whole internet just cracked. I have written before about cleaning up a hacked server that a backup could not have saved. Patching on day one is how you avoid writing that kind of story about your own clients.

If you run a PHP website and you are not sure who is responsible for patching it, find out today. Not next week. Exploitation attempts were seen even before the public announcement, and they have only increased since.

The headlines got it backwards

What I found amusing over those two days was the way this was being reported.

The vulnerabilities were found with the help of AI tools. Security teams at Calif, Wiz and OpenAI used AI models in their research to dig these flaws out. And a lot of the coverage turned that into a story about AI being dangerous. AI is breaking the internet. AI is causing all of this.

But think about what actually happened.

These flaws were sitting in PHP for over ten years. Thousands of developers, security researchers and automated scanners went over that code in that time. Humans, using traditional methods, did not find them. Or if someone did find a piece of it, nobody realised how serious it was. AI helped find them. Then the people who found them reported them privately, the PHP team built a fix, and the fix was released to the world.

That is not AI causing a problem. That is AI finding a problem that already existed and was waiting for someone with bad intentions to stumble on it first. The vulnerability did not appear in October 2026. Only our knowledge of it did.

Panic for a week, then it settles

Now that it has been found and people are patching it, it will be secure. Yes, there will be panic for a week. Some websites went offline while their owners scrambled. Hosting companies are pushing updates. Security teams are working long hours. And then it will settle down, like it always does.

The servers that get patched will be safer than they have ever been. The ones that don't get patched were always going to be a problem eventually, AI or no AI.

There is no need to badmouth AI

Like any technology, AI has a good side and a bad side. The same tools that help a researcher find a bug can help an attacker find one. That is real, and I am not going to pretend it isn't. But that has been true of every powerful tool we have ever built, from the compiler to the internet itself.

I use AI in my own work every day, and we build AI features for clients too. My view, which I have written about when talking about AI that looks great in a demo but does nothing in your business, is that AI is a tool and it is only as good as how it is used. In this case, it was used well.

Expect more of this, and that is a good thing

I am quite sure that in the coming months, and over the next year, AI tools will find many more vulnerabilities like this one. Old ones. Deep ones. In software we all assumed was solid because it had been around forever.

Each one will need immediate attention. Each one will mean a few long days for people like me.

But every one of those discoveries is a hole that gets closed before it hurts someone. I would much rather have AI find these bugs in a research lab and hand them to the maintainers, than have them found quietly by someone who will never report them.

So the practical takeaway for business owners is simple. Software needs looking after. Make sure someone owns the job of keeping your website and applications patched, and make sure they actually do it when something like PHP2Shell lands. If you are not sure whether your site is covered, get in touch and we can take a look.

What was your experience?

I am curious how this played out for others. Were you affected by PHP2Shell? How many servers or sites did you have to patch, and how long did it take you? And how do you feel about the way AI is being blamed for this?

Do share your thoughts with me on LinkedIn, where this started as a post.