Cyberside Chats: Cybersecurity Insights from the Experts

On October 21, the PHP project shipped an emergency fix for two critical bugs, nicknamed PHP2Shell, that let an unauthenticated attacker run code on a web server with a single crafted file upload. PHP runs roughly 70% of the web. Governments pulled websites offline, a major HR platform went dark, and attack attempts were hitting sensors hours before a patch existed.

Your first line of defense may not have been your own. Cloudflare, Akamai, DreamHost and other major providers had protection in place, buying you time — in some cases hours before the patch was even released.

Sherri Davidoff and Matt Durrin explain what happened, why "we patched" isn't proof, and five questions to put to your own team and every vendor that runs PHP for you.

Key Takeaways:

1. Find the PHP you forgot about. The dangerous instances aren't your web farm; they're the backup appliance, the printer, the management console, the exposed controller, the inherited container image. NCSC flagged PHP bundled inside third-party products specifically. Anything on an unsupported version that can't be patched goes off the internet today.
2. Put a maintained layer in front of everything exposed, and still patch behind it. A provider who virtual-patches buys you the hours between “exploit exists” and “patch exists.” But a WAF guards the front door; a phished foothold walks around it to the same bug. Lean on the big providers without letting them become your whole defense.
3. Verify the patch is actually running (don't take “we patched” as done). The update isn't live until every worker is fully restarted, and backported fixes still report the old version number, so the banner can't prove you're safe. Make your team confirm it by package and process, and remember the finders say these two CVEs may not cover every variant.
4. Check with every vendor that runs PHP for you. Most of your exposure is someone else's code: your hosts, your SaaS platforms, the appliances in your racks — and their unpatched server is still your breach. Ask each critical vendor the direct question: have you patched, restarted, and put protection in front? Inventory your own PHP too, and track who can't give you a straight answer.
5. Know who owns emergency patching, and whether they actually caught this one. Someone may already be nominally responsible; this incident is the test of whether that role functions. When the advisory dropped, did your team — internal or outsourced — recognize the urgency and drive the patch, or did it slip by unnoticed? If you had to find out from the news instead of from them, that's the gap to fix before the next one.

Resources:

1. PHP, "Security advisory: Critical remote code execution vulnerabilities, update now" — https://www.php.net/archive/2026.php#2026-10-21-5
2. Cloudflare, "Cloudflare deploys protections against php2shell vulnerability" — https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
3. The Record, "PHP says AI review of critical bugs first sparked alarm in August, but signs surfaced in 2024" (PHP Foundation postmortem) — https://therecord.media/php-foundation-statement-critical-vulnerabilities
4. Sansec, "PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)" — https://sansec.io/research/php2shell
5. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" — https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching