Sitemap
Danilo Stojkovic

Danilo Stojkovic

Founder of PeritumAI. I write about AI governance and cybersecurity: who holds the keys, who watches the agents, and what happens when policy meets production.

The Day AI Switched Off the Internet: A Board-Level Read on PHP2Shell

4 min readOct 21, 2026
Press enter or click to view image in full size

An AI-assisted hunt found two critical PHP bugs. A leak cut the warning to 18 hours. Governments unplugged their own websites rather than gamble. Here’s what happened, and what it says about who owns the software under everything.

On 21 October the Netherlands took DigiD, its citizen login for taxes and healthcare, offline. MijnOverheid, the parliament website and even the National Cyber Security Centre’s own site followed. Finland’s Government ICT Centre, Valtori, pulled public government web services. In Japan, major hosting and gaming services went into emergency maintenance.

None of them reported a breach. They switched off on purpose. For leadership teams, that decision is the most important signal of the week.

What happened, in brief

- Two critical flaws in PHP, CVE-2026–109618 and CVE-2026–109619 (“PHP2Shell”), both rated 9.2 (CVSS v4.0). They allow unauthenticated remote code execution on servers running PHP for the web.

- Wiz Research says every version back to PHP 5.4 is affected by at least one.

- OpenAI says its Patch the Planet initiative led a two-month coalition to prepare the fix. Calif found a critical flaw using an OpenAI model, and Wiz found and reported both on its own. PHP’s maintainers led the release.

- Details leaked on 20 October, two days before planned disclosure. PHP shipped fixes (8.5.12, 8.4.27, 8.3.36, 8.2.35) about 18 hours after its emergency notice.

- Cloudflare reported early attack attempts. As of the afternoon of 21 October, Patchstack and NCSC-NL reported no confirmed breaches.

- PHP 8.1 and older get no official release. About 884,000 internet-facing hosts reported such versions in their banners.

Why governments chose “off”

Going offline is expensive and visible. Organisations do it when they can’t vouch for their own estate. If you can’t say with confidence where every PHP runtime sits (in the CMS, the vendor appliance, the hosting control panel, the forgotten intranet tool), you can’t promise to patch it within hours. The UK NCSC and CERT-EU both endorsed that trade-off: patch, or take systems offline.

That’s not failure. It’s honesty about inventory. But it shows a gap most organisations share.

The governance gap: owners for applications, nobody for runtimes

Get Danilo Stojkovic’s stories in your inbox

Join Medium for free to get updates from this writer.

Most risk registers name an owner for “the website” or “the CRM”. Very few name an owner for the runtime underneath: PHP, Java, Node, OpenSSL. When a runtime-level flaw lands, accountability scatters across application teams, infrastructure, hosting providers and vendors. Each assumes another holds it.

AI makes this sharper. OpenAI says it expects findings like this to “increase sharply in the coming months,” and warns the same capabilities can speed up exploit development. Discovery is getting faster. Organisational remediation, through inventory, change approval and vendor dependencies, mostly isn’t.

Five questions for your next board or risk committee

1. Inventory: Can we list every internet-facing system running PHP today, including vendor and SaaS-hosted components, within one hour?

2. Ownership: Who, by name, owns each shared runtime and its patch SLA?

3. Speed: What’s our real time from critical patch release to production, and is there a pre-approved emergency path that skips the routine change board?

4. End-of-life exposure: What are we running on unsupported versions, and what’s the plan when no official fix exists?

5. Vendors: Do our contracts require suppliers to disclose bundled runtimes and patch critical flaws within a defined window?

What to do this week

- Patch internet-facing PHP to the fixed versions, and confirm the version that’s actually running.

- Isolate or upgrade end-of-life PHP. Treat WAF rules as temporary only.

- Look for signs of compromise on anything that stayed exposed.

- Put “runtime owner” into your asset register and risk framework as a mandatory field.

The takeaway

The fix for PHP2Shell is one update. The hard part was knowing where to apply it. As AI shortens the time between discovery and exploit, inventory and ownership stop being hygiene. They decide whether your organisation patches on Wednesday or switches itself off.

Sources
- PHP announcement (20 Oct): https://news-web.php.net/php.announce/509
- PHP advisory, OOM corruption: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- PHP advisory, stale global state: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- OpenAI, Patch the Planet: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/
- BleepingComputer: https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/
- The Hacker News: https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html
- Patchstack live timeline: https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/
- NCSC-NL via Rijksoverheid: https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/ncsc-ernstige-kwetsbaarheden-in-php
- DutchNews: https://www.dutchnews.nl/2026/10/government-websites-taken-offline-over-hacking-vulnerabilities/
- Yle: https://yle.fi/a/74-20252600
- UK NCSC: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

Originally published at https://www.linkedin.com.

--

--

Danilo Stojkovic
Danilo Stojkovic

Written by Danilo Stojkovic

0 followers

Founder of PeritumAI. I write about AI governance and cybersecurity: who holds the keys, who watches the agents, and what happens when policy meets production.