Subscribe to GEN
Login to GEN
Add a Comment
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.
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.
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 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.
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.
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.
Package management in Oversight; Every Linux host reports what it has installed, what its own repositories offer, and every transaction it runs.
* 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.
To see it on your own estate, visit oversight.im or raise a ticket and we will walk you through it.
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.
This content is not legal or financial advice, and is solely the opinion of the author.