PHP2Shell: Why the Cyber Essentials 14-Day Patching Rule Is a Maximum, Not a Target

On 21 October 2026, the PHP project released emergency fixes for two critical vulnerabilities in PHP itself, the language that sits underneath a large share of the world's websites. Within hours, government websites across Europe and Canada had been switched off as a precaution, and security firms were watching attackers try to break in.
For anyone working towards Cyber Essentials certification, or already holding it, PHP2Shell is a very practical lesson. The scheme's 14-day patching rule is the most you are allowed, not the pace you should aim for. This article explains what happened, what the Cyber Essentials requirements actually say, and the timescales we now recommend.
What is PHP2Shell?
PHP2Shell is the name given to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The NCSC's alert explains that the flaws could let an attacker run commands on any web server running PHP, without needing to log in. Both are rated critical, with a CVSS v4.0 score of 9.2.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches, including PHP 8.1 and earlier, may not receive a fix at all, which matters a great deal for Cyber Essentials, as we explain below.
The bugs were found by researchers using AI tools. Wiz Research reports that every PHP release from the last decade, going back to version 5.4, is affected by at least one of the two flaws. Because WordPress, Drupal, Joomla and countless bespoke systems run on PHP, the exposure is enormous: some estimates put PHP behind more than 70% of websites.
Government and high-profile websites went offline
Details of the flaws leaked online on 20 October, a day before the planned release, and the PHP team brought the fix forward as a result. National cyber agencies responded quickly:
In the Netherlands, organisations followed the national cyber centre's lead and took public websites offline, including the Port of Rotterdam, the government portal Overheid.nl, the national football association, the five largest political parties and several hospitals.
Finland, France and Australia temporarily took government services offline to apply the patch.
In Canada, some federal government websites and the Newfoundland and Labrador provincial sites went dark as a precaution, on the advice of the Canadian Centre for Cyber Security.
In the UK, the NCSC urged organisations to take immediate action and, where systems could not be updated or mitigated quickly, to consider taking them offline until they could be.
When governments choose to switch their own websites off rather than risk a few hours of exposure, it tells you how seriously the people with the best threat intelligence are treating this.
Minutes, not days: AI has collapsed the patch window
Publishing a fix also publishes a map. Once a patch is out, attackers can compare the old and new code to see exactly what was broken, then build an attack against anyone who hasn't updated yet. That has always been true. What has changed is the speed.
Ahead of the release, security firm Sansec predicted mass exploitation within 15 minutes of the patch going public.
Amazon's threat intelligence team saw new proof-of-concept exploits appear within hours of the release and used against its sensors almost immediately. It also found one exploit attempt dated 17 October, four days before public disclosure.
Amazon's security chief told The Hacker News that AI-assisted analysis makes it cheaper to turn a patch or advisory into a working exploit, so more attackers can act within hours or even minutes of details being disclosed.
Experts quoted by The Record said that with AI, most attackers can now produce a working exploit in under an hour.
None of this is a surprise to the NCSC. In May 2026, its Chief Technology Officer warned organisations to prepare for a vulnerability patch wave, because AI in skilled hands is exposing old flaws at scale and at pace. The NCSC's advice was to prepare to patch quickly, more often and at scale, to switch on automatic updates wherever possible, and to adopt a policy of updating by default.
What Cyber Essentials actually requires
The current standard, Cyber Essentials: Requirements for IT Infrastructure v3.3, sets out the Security Update Management control. All software on in-scope devices must:
be licensed and supported
be removed when it becomes unsupported, or moved out of scope into a sub-set with no internet traffic
have automatic updates enabled where possible
be updated within 14 days of release where the update fixes vulnerabilities rated critical or high risk (CVSS v3 base score of 7 or above), or where the vendor gives no severity details
Two details are easy to miss. First, the scheme's definition of software explicitly includes interpreters, scripts and libraries, so PHP on an in-scope server or cloud platform is squarely covered. Second, the NCSC itself says updates should be applied as soon as possible, and describes 14 days as a reasonable period, with anything longer being a serious security risk. Fourteen days is the outer limit the scheme will accept. It is not a recommended schedule.
If you are still running PHP 8.1 or older and your provider is not supplying security fixes, the software is unsupported. That is a Cyber Essentials non-compliance on its own, regardless of PHP2Shell. Our article on the April 2026 Cyber Essentials requirements explains how strictly the current question set treats the patching questions.
Our guidance: 14 days maximum, 7 days recommended, hours where it counts
As a Cyber Essentials Certification Body, this is the standard we now recommend to every applicant. To be clear, the 7-day and same-day figures below are our recommendations, not scheme requirements.
14 days: the absolute maximum. Miss it on an in-scope high or critical update and you are not compliant.
7 days: our recommended standard for all high and critical security updates, so that a slow week, a holiday or a failed update doesn't push you past the deadline.
Hours: for anything critical, internet-facing and under active attack. This matches the NCSC's guidance on responding to active exploitation, which says that for a known-exploited flaw on an internet-accessible system, where attacks can be automated and give an attacker full control, the update should go on immediately, within 24 hours.
Looking ahead, we expect that window to keep shrinking. If attackers can turn a published fix into a working exploit in under an hour today, it won't be long before the realistic patch window for internet-facing systems is measured in minutes. The organisations that cope will be the ones that have automatic updates switched on, know exactly where their software runs, and have agreed in advance who can take a website offline at short notice.
Protecting from the PHP vulnerability: what to do now
Find every copy of PHP. Not only your website, but also hosting control panels, customer portals and any appliance that bundles PHP. The NCSC points to an inventory list from NCSC-NL of products with a PHP dependency.
Update to a fixed version (8.5.12, 8.4.27, 8.3.36 or 8.2.35) and restart the PHP services so the fix actually takes effect.
If someone else hosts it, get confirmation in writing that the update has been applied, with the date.
If you can't update straight away, apply the PHP team's temporary mitigations, put a web application firewall in front, or take the site offline.
Check for signs of compromise. Amazon recommends investigating from at least 17 October. If you're not confident doing this yourself, the NCSC lists assured incident response providers.
Retire unsupported PHP versions and plan the upgrade now, before the next critical flaw.
For a step-by-step look at meeting the patching requirement day to day, read our guide to how to actually meet the Cyber Essentials 14-day patching rule.
Guidance for your sector
We've published shorter, practical pieces on what PHP2Shell means for different organisations. Browse them by category: MSPs and IT support providers, accountancy, charities, education, financial services, legal, micro organisations, SMEs and corporate organisations.
Why this is a Cyber Essentials story
The NCSC's own response to the patch wave is to point organisations back to fundamentals, including adopting Cyber Essentials in full. One of the clearest Cyber Essentials benefits is that it forces the habits that protected people this week: knowing what software you run, keeping it supported, and updating it quickly.
If you're wondering how to get Cyber Essentials and want an assessor to check your patching before you submit, our Cyber Essentials Supported service does exactly that. Not sure which route suits you? See Marking Only vs Supported, or call us on 0333 339 0383.
Sources
NCSC: Critical security issue affecting PHP (21 October 2026)
NCSC: Preparing for a 'vulnerability patch wave' (1 May 2026)
NCSC: Cyber Essentials Requirements for IT Infrastructure v3.3 (April 2026)
Reuters via US News: Government websites go dark after AI-discovered flaw
Amazon Threat Intelligence: PHP2Shell exploitation prior to disclosure
The Hacker News: Exploit attempt four days before disclosure
Infosecurity Magazine: PHP vulnerabilities leaked ahead of patch
University of Washington IT: fixed versions and unsupported branches




Comments