Processing...

 PHP2Shell: A Critical Score, a Modest Risk, and 3,900 Hosts Patched

The Curious Codex

Two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026 to a global reaction out of proportion to the real risk. How GEN patched around 3,900 client hosts within minutes of the packages appearing, and why our own servers went last.

23 October 2026 Published 23 October 2026 Updated 1,090 Words 6 Minute Read
Blog Index 0 Votes
The Author
Richard (Senior Partner)LinkedIn

Richard has been with the firm since 1989 and is one of the founding partners

PHP2Shell: A Critical Score, a Modest Risk, and 3,900 Hosts Patched

Two vulnerabilities rated 9.2. Public websites switched off across Europe. Around 3,900 client hosts patched from the moment the fixed packages appeared, about 30 minutes after release, and our own servers last.
This is what PHP2Shell actually was, and how we handled it.



What Landed on Wednesday

On Wednesday 21 October 2026, at 15:00 UK time, the PHP project released fixes for two vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, which quickly became known as PHP2Shell. Both are rated 9.2 under CVSS v4.0 and are described as allowing remote code execution without authentication. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything older is affected, including the branches that no longer receive fixes at all.


The PHP project gave advance notice, so our Cyber Alert went out to customers that morning and the work was planned before the release arrived.



The Reaction

The response around the world was dramatic. Government security agencies advised organisations that could not patch immediately to take their websites offline or isolate them, and many did: council and police websites in the UK went dark on Wednesday, as did government sites elsewhere in Europe. The figure quoted everywhere was that PHP runs around 70% of the web, and from there it was a short step to headlines suggesting most of the internet was open to attack.


Some of the coverage struggled with the basics. We watched one national news report on the vulnerability that could not quite say what PHP is, which is a fair measure of how far the story had travelled from the technical detail. Running PHP and being exploitable by these two flaws are not the same thing, and the gap between them is where the real risk sits.



The Real Risk

A CVSS score describes the worst that is possible, not what is likely, and here the practical picture is far narrower than the headline. Exploiting either flaw is difficult. Realistically, the most an attacker can do is read a file from disk, and only a file they already know the name of, can reach, and can make sense of once they have it. That is a long list of conditions to meet on someone else's server.


Even the remote code execution, where it can be achieved, runs as the PHP-FPM user: an unprivileged account with no business anywhere outside the application it serves. On a properly built host SELinux confines that account further still, so code running as it stays in its box. None of this is a reason to delay a patch. It is a reason not to take a website offline over one, and a good illustration of why layers matter: a well-built host turns a critical vulnerability into a contained one.



How We Patched

The PHP project's release is the source code. The packages our hosts actually install come from Remi's repositories and el9/el10, which had to build and publish their own updates, and those appeared about 30 minutes after the official release. Patching started the moment they did, automatically, and was done in record time.


Client hosts went first: around 1,700 classed as high risk, largely where the client had asked for priority, then around 2,200 as lower risk. Our own servers went last, between 16:32 and 17:41. That order was deliberate. Our clients come first, our own estate could wait an hour, and it is the one place where we can deal with any fallout ourselves, on our own time.



Effortless

Package management in Oversight; Every Linux host reports what it has installed, what its own repositories offer, and every transaction it runs.


Oversight Packages, Search tab: php*cli across all hosts, 4 packages on 7 hosts, 7 with a newer version waiting, and a single button to upgrade on all 7.


* An anonymised oversight screenshot based on a real client with real assets


Some hosts carry more than one PHP version side by side, and that does not mean all of them are in use. Most sites run on the newest, and the previous version stays installed and patched as a fallback: if something turns out to be broken on the new one, a site can be switched back with a single change while it is fixed.


One search across every host and every PHP stream on each, what is installed against what is waiting, and one button. Search for CVE-2026-109618 instead, and it lists every host with an update waiting that fixes it, from the advisories each host's own repositories publish. Each host upgrades only what the search matched, reports the full transaction back, and reboots only if it says it needs to, and a reboot only counts as done when the host checks in again on its new boot.


  • No way in. The agent opens no port and needs no SSH. Every host calls out to Oversight over HTTPS, signed with its own key, and instructions come back in the reply, so hosts behind NAT or on a customer's own network work the same way.
  • Every distribution, one page. AlmaLinux, Rocky and RHEL with dnf, Debian and Ubuntu with apt, Arch and Manjaro with pacman, each compared by its own versioning rules.
  • A record of everything. Every package change is matched to the transaction that made it, so the log says who upgraded what and how, not just that something changed.
  • Alarms for what should not happen quietly. A package no transaction explains, a new repository, a new start-up or scheduled entry, or a kernel, microcode or BIOS change nobody asked for.
  • Care where it matters. Virtualisation hosts are held back from bulk upgrades unless deliberately included, because restarting their services takes every guest down with them, and what is refused is configurable by host on the host, and refused by that host.

To see it on your own estate, visit oversight.im or raise a ticket and we will walk you through it.



The Point

PHP2Shell was real, and it was patched quickly, everywhere we are responsible for. It was never the threat to the internet that the coverage suggested, and switching websites off was a larger self-inflicted outage than the vulnerability was ever likely to cause. A well-built host, an unprivileged service account, SELinux, and the ability to patch thousands of hosts within minutes of the packages appearing are what make a 9.2 something to deal with calmly, rather than something to panic over.


Point, Click, Done.


Blog Index 0 Votes
×

This content is not legal or financial advice, and is solely the opinion of the author.