PHP2Shell showed that patching PHP is straightforward, but knowing every place PHP runs across an organisation is far harder.
On 21 October 2026 the PHP project released emergency fixes for two critical flaws in the PHP engine, which researchers have named PHP2Shell. Most IT teams moved quickly to update the web servers they knew about. A week later, the more useful question for many organisations is no longer whether they have patched, but whether they have patched everything that needed it.
This is the first of three articles in a series, Lessons from PHP2Shell, written for IT staff in UK businesses from small firms to large enterprises. PHP2Shell serves as the worked example throughout, but the underlying questions apply to any widely shared software component: how an organisation keeps track of the software it runs, how quickly it can patch it, and how it confirms that a patch has taken effect. This first part covers servers that the organisation manages directly, and sets out the background to PHP2Shell and the patching timescales that apply in the UK. Part 2, The Software You Can’t See, deals with containers and other places where software is bundled out of view. Part 3, The Software You Can’t Touch, deals with appliances and hosted services, where the fix depends on a vendor.
What is PHP2Shell?
PHP is a programming language that runs on web servers and builds pages as visitors request them. It underpins WordPress, Drupal, Magento and Nextcloud, among many others, and it also runs the management pages of many network devices. PHP2Shell is the name given to two flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, reported by researchers at Wiz, OpenAI and Calif. Both arise from the way PHP tidies up when a request goes wrong, and both can be exploited to run commands on a server without logging in. The PHP project rated them 9.2 out of 10 for severity.
Two features made them unusually serious. The vulnerable code dates back to PHP 5.4, released in 2012, so almost every installation serving web pages was affected. And because the flaws sit in PHP rather than in the application, updating WordPress or its plugins did nothing to fix them.
How the first week unfolded
Amazon observed an exploitation attempt on 17 October, four days before disclosure, and details leaked online on 20 October after the PHP project announced an emergency release. Several organisations took websites offline as a precaution, including the Dutch House of Representatives and, in the UK, a number of councils and the Metropolitan Police. The fixed versions, PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, followed on 21 October, alongside an NCSC alert urging organisations to find every PHP installation, watch for vendor updates and consider taking unpatchable systems offline.
On 23 October the PHP project warned of a third, related flaw, CVE-2026-115560, which requires an unusual configuration and will be fixed in a routine release. By the weekend of 24 and 25 October researchers had confirmed working attacks against decoy servers, and Delft University’s Threat Intelligence Lab has since recorded more than 50,000 exploitation attempts from over 600 addresses in 70 countries.
Visibility and control
It helps to think about exposure to PHP2Shell along two lines. The first is visibility, meaning whether the organisation knows that a particular copy of PHP exists. The second is control, meaning whether the organisation can choose which version of PHP runs or must rely on a supplier to change it. Taken together, these give four broad situations. The label in each box shows which part of this series covers it.
The three parts of this series follow this grid. Servers that an organisation manages and knows about fall in the top left, where the work is largely a matter of patching quickly and then checking that the patch took effect, and they are the subject of this article. Containers and other bundled runtimes fall below them: the organisation can usually update them, but the software inside is easy to overlook, and some containers are never recorded at all. These are covered in Part 2. The two right-hand cases, where a vendor controls the version, are covered in Part 3.
Keeping an inventory of server software
Most organisations keep a list of their servers, but fewer keep a list of the software components running on each one. When PHP2Shell was announced, the useful question was not how many servers the organisation had, but which of them ran PHP, and which version. The same question would apply to the next flaw in OpenSSL or any other shared library.
On Linux servers, the package manager already holds most of this information, so the task is to collect it centrally. Configuration management tools such as Ansible, or the agents that come with most vulnerability scanners, can report installed packages and versions from every server into one place. The result should be searchable by component, so that a single query can show every server running a given package. The NCSC lists identifying assets as one of the core principles of vulnerability management, and an inventory at this level of detail is what makes rapid patching possible.
Patching servers quickly
The NCSC recommends a policy of updating by default, with security updates applied automatically wherever possible. On Linux this usually means enabling the distribution’s automatic update tool, such as unattended-upgrades on Ubuntu or dnf-automatic on Red Hat systems, at least for security updates. Where automatic updates feel too risky for business-critical systems, the NCSC suggests a phased rollout, for example updating a tenth of the estate each day and pausing if problems appear.
Two details are easy to miss. Updating a package does not change a program that is already running, so PHP worker processes must be restarted before the fix takes effect. The same applies to the temporary mitigation the PHP project published, which only works if it is set in the server-level PHP configuration rather than inside an application. Servers running PHP 8.1 or older also need separate treatment, since the PHP project only released fixes for versions 8.2 to 8.5; for older versions, a backported fix from the distribution or an upgrade is required.
Proving the patch worked
A patch job that reports success is not proof that a server is protected. Where PHP comes from a Linux distribution, the fix is often backported into the existing version, so php -v can show a version number that looks out of date on a server that is safe, and the reverse can also happen. The reliable check is to compare the installed package against the distribution’s own advisory, such as Ubuntu’s USN-8948-1 or Debian’s DSA-6574-1. An external vulnerability scan of internet-facing servers after patching provides a second, independent view, and the results are useful evidence for Cyber Essentials assessments.
Patching timescales
For many UK organisations, the working deadline is set by Cyber Essentials, which since April 2026 has strictly required high and critical updates, including firmware, to be applied within 14 days. That figure is the minimum for certification rather than good practice, and the NCSC’s own guidance sets shorter targets for routine updates:
| Type of system | NCSC best-practice target |
|---|---|
| Internet-facing services and software | 5 days |
| Operating systems and applications | 7 days |
| Internal or air-gapped systems | 14 days |
The NCSC adds that these targets are too long when a flaw is being exploited at scale. Australia’s Essential Eight framework goes further, expecting internet-facing services to be patched within 48 hours when an exploit exists.
The case for faster patching rests on how quickly attackers now move. Mandiant’s M-Trends 2026 report estimates the mean time to exploit in 2025 at minus seven days, meaning that exploitation typically began a week before a fix existed, compared with 63 days in 2018. The average is pulled down by zero-day attacks, and Root Evidence found a median gap of 116 days where attackers waited for a patch. PHP2Shell, however, sat at the fast end of the range, and an organisation that patched on day 14 would have been exposed for 18 days in total.
UK GDPR adds a further consideration. Article 32 requires security appropriate to the risk, and if personal data is breached, Article 33 requires the ICO to be notified within 72 hours. A Cyber Essentials certificate is unlikely to be much defence if a widely publicised, actively exploited flaw was left unpatched.
Patching is not the same as remediation
A patch prevents future exploitation, but it says nothing about whether a server was compromised before it was applied. Because attempts began on 17 October, the NCSC advises checking internet-facing systems for backdoors even where the exposure was brief. The most common is a web shell, a small script that lets an attacker return later, so new or recently modified .php files in upload folders and web roots are a sensible place to start, along with unusual processes launched by php-fpm or apache2.
Where evidence of compromise is found, the NCSC recommends isolating the system, rebuilding it and reporting the incident, using an NCSC-assured incident response provider if the skills are not available in-house. If personal data may be involved, the 72-hour period for notifying the ICO starts once the organisation becomes aware.
The technical response to PHP2Shell was fast, with fixes published within a day of the leak. Where organisations struggled, the difficulty was usually one of knowledge: knowing which servers ran the affected software, and confirming that the fix had taken effect. An organisation that can search its inventory by component, patch automatically and verify the result against vendor advisories will be well placed for the next flaw of this kind, whichever component it affects. Part 2 turns to containers, where the same software is often harder to see.