How quickly could you tell which systems run PHP? On the 21st October 2026, governments across Europe had to answer that question within hours, and several decided the safest answer was to switch their websites off.
The cause was PHP2Shell, two critical flaws in PHP, the language behind around 70% of websites. Attacks began before fixes existed, the affected systems were hard to find, and even applying the patch didn’t always close the gap. So let’s look at what happened, what the challenges were and how to react next time …
PHP is a programming language that runs on web servers. It handles the behind-the-scenes work of websites and web apps, such as pulling content from a database, processing form submissions and building each page before it’s sent to the visitor. WordPress, Drupal, Joomla and Laravel are all built on it, along with a lot of bespoke business software.
PHP sits underneath those applications as a runtime, installed on the server, often by a hosting provider or control panel rather than whoever built the site. It gets updated separately from the software on top of it. That means a flaw in PHP might affect every site and tool running on that server, whatever the application is.
The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2, which makes them critical security issues. Both allow remote code execution with no credentials or user interaction. Remote code execution means an attacker can run their own commands on the server itself, giving them all the privileges of the most senior admin.
Every PHP release before the fixed version is affected, including PHP 5 and other branches long out of support. Fixes arrived on the 21st October in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Versions 8.1 and older are end of life, so PHP published only minimal source backports for 7.4, 8.0 and 8.1 rather than patched releases. Most organisation on those versions depend on packages from vendors such as cPanel and CloudLinux. Palo Alto Networks counted more than 22 million internet-exposed instances.
In the UK, the NCSC told organisations to find every PHP installation and update or apply PHP’s temporary mitigations. In situations where neither could be done quickly, it said to consider taking the system offline. It also advised checking anything that couldn’t be fixed straight away for backdoors.
PHP2Shell was supposed to be a coordinated disclosure. Researchers working with AI models found the flaws in August, and a group of maintainers and security firms spent around two months preparing fixes. That didn’t go to plan: the details leaked on the 20th October and fixes were release on the 21st. Amazon’s threat intelligence team has since reported an exploitation attempt against its honeypots dated 17th October, four days before anyone could patch.
That’s why some governments acted as they did. With fixes only just out and exploitation already underway, they took public sites offline until they were sure. The reason for the rush? The obvious answer is AI, which is speeding up the rate and scope of what attackers can do.
So, does it change what patching quickly needs to mean? A process built around “the vendor releases, we test, we deploy in the next window” assumes the attacker starts the clock when you do, but this time they didn’t. The partners who could act on the day knew which clients ran PHP and where. They also knew which systems could be taken offline or put behind a WAF rule.
Ask a client whether they run PHP. Of those who have an answer, most will think of their website. But in reality, the list is longer. Customer portals, intranets, booking and time-tracking tools, older CRM packages, hosting control panels and the web admin consoles on firewalls, NAS devices and other appliances may all be included. CERT-EU warned that products using PHP as a backend could also be affected, even if they do not directly expose a PHP installation.
PHP bundled inside a product’s firmware doesn’t appear in a list of installed packages. Qualys also pointed out that the version you get from running “php -v” on a server can come from a different installation than the one actually serving web requests. Spread that across a client base where every client has their own hosting setup, and the gaps add up very quickly.
Running processes keep the vulnerable code in memory until they restart. Some servers stayed vulnerable even when the right package was installed on time. If you update the package without restarting, the server might report the new version while still handling requests with the old one.
So, ‘patch deployed’ in an RMM dashboard isn’t the same as ‘fixed’. Verifying the fix means confirming no workers are still running the old build. Patching also does nothing about access an attacker may already have, a point Forrester’s Madelein van der Hout made at the time. That’s why the NCSC’s backdoor warning matters for anything that was exposed from the 17th October onwards.
A part of the NCSC’s advice was to keep track of third-party vendors whose products bundle PHP. A client can patch every server it owns and still be exposed through a supplier’s CRM, file transfer service or status page.
Supply Guard looks for PHP2Shell exposure across your client’s suppliers and partners. It checks the less obvious addresses suppliers run, such as crm., sftp. and status. subdomains, as well as their main websites, and shows which PHP versions are in use. It then tracks each exposure until it’s resolved and asks for evidence that the fix has been applied. For partners, it extends visibility past the systems you manage to the supply chain, which is exactly what clients are now asking about.
Rootshell covers the client’s own web apps and servers. Its penetration testing, delivered as a service through the Rootshell Platform, shows whether an exposed site can be exploited through a flaw like PHP2Shell.
Rootshell’s external attack surface management continuously discovers internet-facing assets, including unknown domains and shadow infrastructure, which is where a forgotten test site or old client portal running PHP will be easy to miss. Add managed vulnerability scanning and real-time exploit detection, and new disclosures get picked up a lot sooner.
When it comes to the commercial side of things, clients who watched government sites go offline are asking their IT providers whether they were affected. Partners who can show what’s exposed, prove it was tested and fixed properly and do the same next time are in a much stronger position for that conversation than those still, or only, relying on a monthly patch report.
AI-assisted research found a flaw that had sat in PHP for years, but attackers have access to the same tools. We can expect more disclosures like this, with less time between leak and exploitation. At Elovade, our select portfolio of vendors enables channel partners to strengthen their clients’ security and IT infrastructure, and Supply Guard and Rootshell are just two examples. Head to our vendor page to learn more or get in touch with the Elovade team and we’ll talk you through how both can fit into your services.