When Governments Pull the Plug: What PHP2Shell Asks of Your Board

This week, the Dutch national cyber security centre took its own website offline. So did a long list of other public bodies across Europe. Not because they had been breached, but because they could not patch fast enough and had decided that a dark website beats a compromised one.

The trigger was a pair of critical flaws in PHP, the programming language behind roughly 70 percent of all websites, according to Wiz's estimate. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and the industry has nicknamed them PHP2Shell. Both carry a severity score of 9.2 out of 10. In plain terms: under the right conditions, a stranger on the internet can send a single request and make your web server run their commands. No password required.

What Actually Happened

PHP announced on October 20 that a security release was coming on October 21. Technical details leaked before the fix shipped, and the fixes arrived on the 21st, ahead of schedule. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP's own advisory says updating is the only complete fix.

Then came the part that should interest every board member. The U.S. National Security Agency issued a rare public warning advising organizations to take systems offline if they could not be updated right away. The UK's National Cyber Security Centre said to consider taking the system offline if it cannot be mitigated in time. CERT-EU, the European Union's cyber emergency team, said to consider isolating internet-facing applications from public networks. The EU ordered nothing. Each national agency and ministry made its own call, and many chose to go dark.

Here is the detail I would put in front of your directors: reporting says the flaws were found with the help of AI. The security firm Calif reported the first flaw in August, working with OpenAI, and Wiz reported the second weeks later. Calif said human expertise still mattered and that no model simply finds all bugs with simple prompts. But the direction is clear. The PHP Foundation said AI will make such weaknesses easier to find and that the number of reports will keep growing.

One honest caveat: sources disagree on whether the flaws are being exploited. Cloudflare's CTO and others reported early attacks, while the Australian Cyber Security Centre and the Dutch national centre had not confirmed active exploitation. CERT-EU said that circulating proof-of-concept code raises the likelihood that attackers are already at work. Plan as though they are.

Why This Is a Board Conversation

The question is not "are we patched?" It is "can we make this decision in an hour?" In Cyber Risk Is Business Risk, the first of the Three Questions is simple: what are we protecting, and what would it cost us to lose it? PHP2Shell turns that into a live drill. Someone in your company has to decide whether a revenue-generating website goes dark until a patch is applied. That is a business decision with a dollar figure attached, not a technical one. If the first time your executives discuss it is during the incident, you will lose hours.

You cannot patch what you cannot find. The NCSC's first instruction is to identify every PHP installation. PHP hides inside content management systems, e-commerce platforms, vendor appliances and that campaign microsite an agency built three years ago. CERT-EU specifically warns about third-party products that embed PHP. If your inventory is incomplete, your exposure is unknown, and "unknown" is not an answer a regulator or plaintiff's lawyer will accept.

Compliance does not cover this. Your last audit probably passed. Audits check that a patching process exists, not that it can absorb a critical fix with leaked exploit details and a few hours of lead time. This is the compliance-versus-security gap I write about in the book. Passing the audit and surviving the week are different tests.

End-of-life software is now a liability, not a line item. PHP 8.1 and older no longer receive official updates from the project, and CERT-EU tells those users to get vendor backports or move to a supported version. PHP 8.2 reaches end of life on December 31, 2026. A budget deferral on a platform upgrade is a decision you will have to defend.

Oversight has a paper trail. Directors who ask about this now are exercising the oversight courts and regulators expect. Directors who learn about it from a headline are in a weaker position.

What to Ask Your CISO This Week

1. Do we know every system that runs PHP, including those our vendors run for us? Ask for the list, and ask how complete it is.
2. Which of those are internet-facing, and which are on PHP 8.1 or older? Those are the urgent ones.
3. Have we patched, and how do we know? Ask for evidence, not reassurance.
4. If we could not patch a critical system today, who has the authority to take it offline, and have we pre-agreed what that costs us?
5. Have we checked for signs of compromise on systems that were exposed before patching? The NCSC advises this for anything that could not be updated promptly.
6. What is our plan for the next one? Because with AI accelerating discovery, there will be a next one, and the gap between disclosure and exploitation keeps shrinking.

The Bottom Line

The governments that went dark this week were not failing. In several cases they were doing exactly what a prepared organization does: weighing the cost of downtime against the cost of compromise, and deciding quickly. The question for your board is whether your company can make that same call, with that same speed, and whether anyone has the authority to make it.

That is the difference between a security program and a security posture. One lives in a policy binder. The other shows up on the worst Tuesday of the year.