Wes Roth's "they're shutting it DOWN" ties a real, serious PHP security release to Dutch government website outages and a much larger fear about the web. The reason to pay attention is real: two flaws in PHP itself can permit unauthenticated remote code execution on affected web servers. The reason to stay precise is just as real: precautionary shutdown, vulnerable software, observed attack traffic and confirmed compromise are four different things.
On 21 October 2026, the Dutch government took several PHP-backed sites offline while fixes were being released. Its notice said there was no indication of active exploitation at that moment; it did not say those sites had been breached. PHP published fixed releases the same day. PHP's 23 October follow-up adds a narrow session-upload-progress warning for a particular configuration. Operators need to patch and check that follow-up. Ordinary readers do not need to stop using the web, but should keep normal account and device defenses in place.
Watch Wes Roth's Video
This post uses the supplied transcript to follow the episode. The linked chapters are editorial markers, not an official chapter list. Claims about the incident are checked against the organizations involved.
Why Dutch Government Sites Went Offline
The Dutch government notice names Overheid.nl, MijnOverheid.nl and DigiD among websites taken offline out of precaution on 21 October. It says a large share of government sites, including Rijksoverheid.nl, do not use PHP and were not affected by this PHP vulnerability. The notice was updated when security releases became available; it is not a live status page for those services.
The Dutch NCSC advisory calls for urgent updates because the two flaws can be exploited remotely without authentication. A preventive outage buys time to assess and patch a server. It does not establish that someone accessed that server's data. Conversely, the Dutch notice's point-in-time statement about no observed exploitation is not a guarantee that no one attempted it anywhere: Cloudflare later reported attack traffic targeting its customers after information leaked ahead of disclosure. Attempted traffic is not proof that a particular government site was compromised.
What AI Helped Uncover
The PHP project's security notice identifies CVE-2026-109618, where out-of-memory handling can leave partially initialized request data that cleanup treats as valid, and CVE-2026-109619, where stale internal state can be used by a later request in the same worker. These are runtime memory-safety failures, not a malicious WordPress plugin or a defect that updating a theme alone would solve.
Calif Research describes starting with a human hypothesis about old PHP memory-limit bugs, then using a language model to inspect related failure paths. OpenAI says Calif used GPT-5.6 Sol within Patch the Planet, while Wiz independently found and reported both vulnerabilities and tested exploitability. PHP maintainers led the fixes. The fair takeaway is AI-assisted security research with human validation and coordinated disclosure, not a model autonomously fixing the web.
The video's other stories, including a weak certificate key, should not be read as PHP2Shell effects. They have different causes and response paths. Likewise, its suggestion that everyone should stay off the web for days is not advice found in the cited PHP, Dutch NCSC or UK NCSC guidance.
Finding a Flaw Was Only the Beginning
Discovery had to turn into verified fixes, provider rules and deployments. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. Linux distributions and long-term-support vendors may provide backported packages with different version strings. PHP warns that temporary mitigations reduce particular attack paths, but do not replace the update. Cloudflare deployed WAF rules for customers, then documented observed attempts to change the attack traffic. A WAF is defense in depth, not a substitute for a fixed origin server.
New on 23 October: PHP published an informational advisory for a separate, unlikely RCE vector involving session upload progress. It requires an unusual combination: an application configured with the php_binary or php_serialize session handler, switching to php at runtime before session_start(), with upload progress still enabled. PHP advises affected operators to set session.upload_progress.enabled=0 until the next regular bugfix release; applications that never switch handlers at runtime can leave the feature enabled. PHP says a full advisory for CVE-2026-115560 will accompany that release. This follow-up is not a reason to postpone the 21 October fixes.
What Website Operators Should Do
- Identify the PHP instance serving web requests. A terminal's
php -vcan describe a different CLI build; check the FPM pool, Apache module, container image or hosting provider actually handling traffic. - Apply a fixed PHP release or vendor-confirmed backport for both CVEs. Restart the affected workers and verify the deployed runtime, not just the installed package. If you cannot patch immediately, follow PHP's temporary guidance and the NCSC advisory while planning the update.
- Review the 23 October session advisory against your configuration. If its handler-switch condition applies, disable upload progress as PHP recommends and restart workers; note any upload-progress feature your users will lose.
- Investigate exposure separately from patching. Review provider alerts and relevant access, application and worker logs for suspicious activity. If evidence suggests compromise, use your incident-response process and rotate affected secrets as appropriate. A vulnerability finding alone does not prove data theft.
For the memory-failure mechanics and the two official advisories, see our technical PHP2Shell explainer. This is a triage guide, not a substitute for your vendor's deployment instructions.
What Everyone Else Should Do
If you only visit a PHP-backed site, you cannot patch its server. Follow service-status and security messages from the site's official channels, not alarming links in unsolicited email or social posts. The UK NCSC's public checklist is still the sensible baseline: update devices and apps, protect email with a unique strong password, use a password manager, turn on two-step verification and keep backups. Those steps reduce common account risks; they do not certify a website as safe or repair a server-side PHP flaw.
The scale of PHP makes the vulnerability urgent for operators. It does not mean that every PHP website has been taken over, nor does the official record support a blanket instruction to abandon normal browsing.
Video Chapters
| Time | Topic |
|---|---|
| 00:00 | The warning and other security headlines |
| 02:46 | Dutch websites taken offline as a precaution |
| 04:25 | Cloudflare and reported attack traffic |
| 05:06 | Practical account and device precautions |
| 07:24 | A separate certificate-authority story |
| 10:12 | How the PHP2Shell research began |
| 14:00 | AI-assisted review and the historical comparison |
| 15:30 | The video's speculative internet-lockdown scenario |
Sources and Evidence Limits
Video: Wes Roth's episode and the supplied transcript. Official response: Dutch government notice, Dutch NCSC advisory, PHP security release and 23 October follow-up. Research and protection: Calif, Wiz, OpenAI and Cloudflare. Public advice: UK NCSC. Checked 23 October 2026. We did not independently inspect the Dutch sites or verify whether any individual server was compromised.