This morning we wrote about why the PHP2Shell update needs doing today. This is the follow-up: what we actually did, the bits that weren't straightforward, and one thing that's catching people out this morning.

The easy part: patch and restart

The fixes for CVE-2026-109618 and CVE-2026-109619 came out on the afternoon of 21 October. On a server running a supported version of PHP from a mainstream Linux distribution, the job is simple. Install the updated packages, then properly restart the web server and PHP.

That second step matters more than it sounds. On one of our servers the package had been updated but Apache had only been given a gentle reload. Every worker was still running the old, vulnerable code from memory. A full restart fixed it. If you've patched your own servers, it's worth checking yours did the same.

Before the fixes were out, we also switched off the PHP feature the published attack relies on, on every server, and locked most of the web servers down so they only accept traffic through Cloudflare. That bought time, but it's a stop-gap, not a fix.

The hard part: PHP too old to patch

The PHP project only fixes versions 8.2 to 8.5. Some of the servers we look after were running much older PHP, as far back as 5.4. That's not unusual for business systems that have quietly done their job for years. But there is no patch for those versions, and there never will be.

For those, the only real fix is to move the site to a new server with a current, supported PHP. Overnight we built new Ubuntu 24.04 servers and containers running PHP 8.3, copied every site and database across, and fixed the code that broke on the newer PHP. Old code always breaks somewhere. Functions that were removed years ago, stricter rules about types, that kind of thing.

Then we checked the new copy against the old one, page by page, using real requests from each site's own logs, before switching anything over. Most switchovers took a couple of minutes. The old servers are still there, switched off, in case we need to roll back.

A couple of very old sites couldn't be moved safely in one night. Those are switched off for now, and we've spoken to the owners directly.

Once everything was patched, we also went through the live servers looking for any sign that someone had tried the attack before we got there. We found nothing.

Why your scanner might still say "vulnerable"

This one is catching people out. Security plugins and scanning services often decide whether you're safe by reading the PHP version number. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, so anything lower gets flagged.

The catch is that Ubuntu and Debian don't change the version number when they patch. They copy the fix into the version they already ship. So a fully patched Ubuntu 24.04 server still says PHP 8.3.6, and a scanner that only reads the number will tell you it's out of date.

The way to check for real is the package version and its changelog. On our servers the package is 8.3.6-0ubuntu0.24.04.13, and the changelog lists both CVEs as fixed. If you get an alert like this and your host runs Ubuntu, ask them for that, not just the version number.

Some scanners also work from old data. One alert this morning listed a site at a version it hadn't run since before midnight.

Where AI fitted in

We use AI tools for a lot of our work, and we're open about how. Last night they were a big part of why this took one night and not two weeks. They read through years of old code to find what would break on PHP 8, wrote and tested the fixes, and did the tedious page-by-page comparisons.

But every decision about what to move, when to switch over and when to stop was made by a person who knows Linux servers. Several times the tools were confidently wrong, and that only gets spotted if you know what right looks like. AI made the work faster. It didn't make it safe on its own.

If your servers aren't sorted yet

If you run your own servers, or someone else hosts your PHP sites and you're not sure they've been done, now's the time to check. Old PHP that can't be patched is the one to worry about most. The longer it's left, the more likely someone finds it.

We can check where you stand, patch what can be patched, and move what can't. That's day-to-day work for us through our Linux server management service, and if the code itself is the worry, a legacy code audit is a good place to start. Or just get in touch and tell us what you've got.

Cheers, Rob