The immediate damage from PHP2Shell came from organisations pulling the plug on their own services. At the time of writing, neither the UK government or its European counterparts had confirmed a single compromise.
The PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) were disclosed on 21 October 2026. Frontier AI models, including GPT-5.6 Sol and Gemini 4 Argon had helped researchers demonstrate exploit against a 14-year-old memory flaw in the PHP engine itself. PHP is the language behind around 70% of websites and within hours of the advisory, Cloudflare reported blocking millions of exploit attempts.
In the UK, 32 government services went offline as a precaution, as did local authorities and the Office for Budget Responsibility. Major financial and transport services in Europe and Japan did the same.
For governance, risk and compliance (GRC) leaders, PHP2Shell was a stress test of cyber governance across both public and private sectors, demonstrating with brutal efficiency that an organisation can be fully "compliant" on paper and suffer no breach, yet still fail on operational resilience.
The death of the 14-day patching window
For years, compliance frameworks and internal risk policies aimed to patch critical vulnerabilities within 14 days. This is a figure set by the UK's Cyber Essentials scheme, and a common target in ISO/IEC 27001:2022 programmes. PCI DSS permits a longer maximum patching period for critical patches and allows one month.
The 14 day benchmark was written for a world where turning a vulnerability advisory or a code patch into a reliable, working exploit took human specialists weeks of painstaking effort. What changed in August 2026 was the economics of exploitation. Wiz, one of two firms that found the vulnerabilities, says a single researcher using commercially available models did in about a week what would once have taken a team months.
If your vulnerability management policy sets a 14-day remediation service level agreement (SLA) for internet-facing critical assets, your governance framework is potentially agreeing to a 13-day window of active exposure. Your Audit and Risk Committee must review your remediation SLAs against AI-compressed threat timelines now.
The availability trap
In the days after 21 October, organisations across the UK, Europe and Japan sacrificed availability to protect confidentiality and integrity, the other two legs of the CIA triad.
The UK's National Cyber Security Centre advised organisations that could not patch immediately to consider taking their systems offline. Given the circumstances, this was a critically important precautionary measure. However, the situation also highlighted valuable lessons in cyber resilience, particularly the importance of strengthening two key areas of governance to help organisations better protect the integrity and availability of their services during future incidents.
The first was poor asset visibility. PHP2Shell lived in the PHP engine itself, so even a benign web page was vulnerable. An organisation that could not find, within hours, every server, container and third-party appliance running PHP in its estate could not be sure it had patched everything.
The second was technical debt. The PHP Foundation released patches for the four supported branches, PHP 8.2 to 8.5. The vulnerabilities reach back to PHP 5.4, so every end-of-life branch from 5.4 to 8.1 remained exposed with no official fix.
Under ISO 27001 and the business continuity standard ISO 22301:2019, precautionary shutdowns of critical services can constitute significant operational incidents, even when undertaken to prevent further risk. They highlight how unmanaged technical debt and incomplete software bills of materials (SBOMs) can undermine an organisation’s ability to maintain service continuity and operational resilience.
Supply chain blind spots
Third-party risk management programmes routinely put commercial SaaS vendors through exhausting questionnaires. However, the open source code those vendors rely on is often a blind spot and not routinely considered in due diligence exercises.
Until now, enterprise risk models implicitly relied on the assumption that deeply buried memory-corruption flaws in mature codebases were simply too hard and too expensive for attackers to find and exploit at scale. The role of AI in vulnerability exploitation has not only brought these flaws into scope but also exposed how few people maintain the software that runs most of the web.
In a candid post-mortem, the PHP Foundation admitted that leaving the flaw unfixed after an external security audit in 2024 was a "structural failure" caused by limited resources and difficult backward-compatibility decisions. This workload is growing as AI tools surface bugs faster than ever.
Supply chain assurance must cover the open-source dependencies beneath your Tier-1 commercial suppliers, under ISO 27001 Annex A controls A.5.19 to A.5.22 (supplier relationships) and A.8.8 (Management of technical vulnerabilities). AI has made vulnerabilities far cheaper to find. It has not made the human governance of fixing them any cheaper.
Moving from point-in-time compliance to continuous resilience
PHP has since warned of a third, related issue (CVE-2026-115560). It will be fixed in the next regular release, with no further emergency patch.
The UK AI Council made a statement earlier this month: "Any organisation that is not using AI to defend itself is now defending against people who are using it to attack." The same principle applies to governance. You cannot govern AI-accelerated threats with analogue, point-in-time compliance processes.
Four actions should top the agenda at your next Audit and Risk Committee:
- Stress-test your remediation SLAs. Separate your compliance minimums from your operational targets. For internet-facing infrastructure, measure your time-to-patch in hours.
- Mandate live software inventories. Extend your asset inventory under ISO 27001 control A.5.9 (Inventory of information and other associated assets) down to runtime environments and open-source libraries, using automated SBOMs. If a critical dependency breaks tomorrow, you must be able to locate every instance across your estate within a single working day.
- Treat end-of-life software as an active board-level risk. Running unsupported softwaremeans that when an AI-discovered zero-day hits, you will be left with either compensating controls or an emergency shutdown.
- Integrate AI and cyber governance. If you adopt ISO/IEC 42001:2023 alongside ISO 27001 and ISO 22301, use them to govern how your own security teams deploy AI to triage vulnerabilities and validate patches faster than attackers can exploit them.
How LRQA can help
All four actions depend on knowing what you run and how quickly you can patch it.
- LRQA's consultant-led Baseline Information Security Assessment gives leadership an evidence-based picture of asset visibility, vulnerability management and supplier controls.
- Our ISO 27001 gap assessments and internal audits test whether your remediation SLAs and asset inventories hold up in practice.
- Where governance capacity is the constraint, our vCISO (virtual chief information security officer) service can help set risk appetite and challenge patching targets at board level.
- Our supplier risk and ISO 42001 services extend the same discipline to open-source dependencies and to the AI tools your teams use.
- Our offensive security team can confirm what an attacker can reach today. If you find PHP2Shell exploited in your estate, our incident response team can help.