Large Organisations and PHP2Shell: Applying the NCSC's Active Exploitation Timelines
For a large organisation, the hard part of PHP2Shell wasn't applying the update. It was knowing, within hours, every place PHP was running across a sprawling estate, getting the right teams to act on a P1 timeline, and deciding which public services could safely be switched off while that happened.
The two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026. Our main article covers the timeline, the government services taken offline across Europe and Canada, and the evidence on AI-accelerated exploitation: PHP2Shell and the Cyber Essentials 14-day patching rule. Here we focus on the governance and discovery questions that matter at scale.
The NCSC timeline you should be working to
The NCSC's guidance on responding to active exploitation of vulnerabilities sets out compressed update timelines for known-exploited vulnerabilities in business-critical systems, each paired with an investigation by an assured Cyber Incident Response provider:
Internet-accessible, automatable, total control: update immediately, within 24 hours.
Internet-accessible, not automatable, total control: within 48 hours.
Not internet-accessible, automatable, total control: within 72 hours.
PHP2Shell, an unauthenticated remote code execution flaw in internet-facing web servers that was being scanned for at scale, sits firmly in the first row. The same guidance recommends using CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) to decide when an issue jumps the business-as-usual queue.
Discovery: finding PHP you didn't know about
The NCSC's PHP2Shell alert told organisations not to limit discovery to outdated PHP versions, but to find PHP installations generally, prioritising internet-facing systems, and to check appliances and services that bundle PHP. In a large estate, that means going beyond the CMDB:
External attack surface data. What does the internet see? The NCSC encourages organisations to have their own external attack surface management capability rather than relying on national alerts.
Vendor and appliance inventories. The NCSC highlights an NCSC-NL list of products with a PHP dependency.
Software bills of materials and code repositories, to find PHP embedded in internally built applications.
Non-traditional sources. The NCSC suggests proxy logs and email gateways to spot business units using products IT doesn't know about.
Shadow IT is where large organisations are usually caught out. Marketing microsites, campaign landing pages and acquired companies' websites are classic examples.
Governance: treat it as a P1
The NCSC recommends that rapid vulnerability remediation is given the same priority as a total system compromise in your IT incident process, and that critical suppliers and managed service providers are contractually bound to fix exploited, internet-facing flaws quickly. If your change advisory process couldn't approve an emergency PHP update on the afternoon of 21 October, fix that before the next one.
Agree in advance who can authorise taking a public service offline. Several governments chose that route for PHP2Shell, and the NCSC advised UK organisations to consider it where systems couldn't be updated or mitigated quickly.
Assume earlier compromise
Amazon's threat intelligence team found an exploit attempt dated 17 October, four days before disclosure, and recommends investigating from that date. Patching does not remove a backdoor already planted, so threat hunting on internet-facing PHP hosts should run alongside remediation.
Keeping Cyber Essentials scope intact
For organisations certified across a whole estate or a defined sub-set, PHP2Shell raises two practical points under Cyber Essentials v3.3:
Interpreters count as software. PHP on any in-scope server, IaaS or PaaS instance must meet the 14-day requirement for high and critical updates.
Unsupported branches must go. PHP 8.1 and older may not be fixed. Legacy systems running them need removing, upgrading, or isolating in a sub-set with no internet traffic.
The NCSC says 14 days is the longest reasonable period, not a target. We recommend large organisations work to 7 days for routine high and critical updates and the NCSC's 24-hour timeline for active exploitation.
Cyber Essentials and Cyber Essentials Plus at scale
For complex organisations, the Cyber Essentials benefits include a consistent, externally verified baseline across subsidiaries and sites, and evidence that supply chain partners increasingly expect. If you're planning how to get Cyber Essentials across a group, or preparing for Cyber Essentials Plus testing, our Supported service starts with scoping, which is where large assessments most often go wrong. See also our guidance on certifying group companies and our corporate resources.
Comments