Talk to us
Menu
BuildTake onLook afterCode auditAIWorkAboutBlogTalk to us01474 639 089

Case study

A whole estate, onto supported PHP overnight

In October 2026 PHP2Shell was published and the official fix only covered PHP 8.2 to 8.5. Some of the client software we look after wasn't going to get one, ever. So we built new servers and moved it that night.

10Servers checked
32Containers checked
15 minStop-gap ahead of the fix
<12 hrsFrom fix to last site moved

What happened

Details of PHP2Shell (CVE-2026-109618 and CVE-2026-109619) leaked a day before the fix. It was the sort of flaw that lets a stranger run their own code on your server. We look after a lot of PHP sites and business systems, spread across 10 servers and 32 containers, and when the fix came out it left some of them behind.

These were live businesses: publishers, back-office systems, client portals. Different servers, different set-ups and different code, all needing checking at once. Waiting wasn't an option, and neither was taking them offline.

The day, in UK time

  • Tue 20 Oct

    Details of the flaw leak.

  • Wed 21, 14:40

    Every server and container checked: which PHP each site runs, and whether a fix will exist for it.

  • 14:45

    Stop-gap applied everywhere. The leaked details showed the way in was a PHP feature most sites never need, so we switched it off. We also locked most of the web servers down to accept traffic through Cloudflare only. Not a full fix, and we didn't treat it as one.

  • 15:00

    Official fix published, PHP 8.2 to 8.5 only.

  • 20:40

    First rebuilt server live.

  • 23:04

    Second rebuilt server live.

  • Thu 22, 02:31

    Last live site moved.

  • 02:41

    Development copies done.

How we did it

  • Patch what can be patched

    Install the updated packages, then properly restart Apache and PHP. That second bit matters. On one server the package had been updated but Apache had only had a gentle reload, so every worker was still running the old code from memory. A full restart fixed it.

  • Build new servers alongside

    For everything the fix didn't cover, a new Ubuntu 24.04 server or container running PHP 8.3, with a snapshot of the old one taken first.

  • Copy, match and adjust

    Every site and database copied across, the old database settings matched so nothing behaved differently, and the code fixed wherever PHP 8 was stricter. Removed functions and tighter type rules, mostly.

  • Compare old against new

    Page by page, using real requests from each site's own logs, before anything was switched.

  • Move the address, not the DNS

    We moved each server's IP address across, so there were no DNS changes to wait for. Most switchovers took a couple of minutes.

  • Mind the crons

    Scheduled jobs like nightly backups and syncs moved with their sites, and never ran on the old and new servers at the same time.

  • Keep a way back

    The old servers were stopped, not deleted, ready to switch back to.

  • Look for footprints

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

Why your scanner might still say "vulnerable"

Security scanners often just read 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.

Ubuntu and Debian don't change that 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. The real answer is in the package version and its changelog. Ours was 8.3.6-0ubuntu0.24.04.13, with both CVEs listed as fixed.

Why it worked.

We already knew this code, and we know these servers. AI tools read through years of old code to find what would break on PHP 8, and did the tedious comparisons, which is a big part of why this took one night and not two weeks.

But every decision about what to move, when to switch and when to stop was made by a person who knows Linux servers. Several times the tools were confidently wrong, and you only spot that if you know what right looks like.

Once we knew the fix wasn't coming for some of our clients' sites, there was no point waiting for one. We moved the software onto supported versions that night. That's what looking after someone's software is for.
Rob Sherwood, co-founder

Where that left everyone

Every live site we kept running ended up on the official fix, a supported vendor patch or a new home on supported PHP. A couple of very old sites couldn't be moved safely in one night, so we switched those off and spoke to the owners directly.

Nobody had to ask us to do this. It's the job. What looking after it means, or if yours is on an old version, what upgrading involves.

Rob went deeper on his own site: why the update couldn't wait, how to check your logs for it and the third CVE that followed.

Related

Our work

From the blog

Where we work

Tell us what you've got

It goes straight to Rob and Jase. You'll hear back from one of us, usually the same day, and we'll tell you honestly whether we're the right people.

Book a call with usor ring 01474 639 089

Just want it checked? Code audit, £250 + VAT