By today, PHP2Shell has made headlines in almost every nation. Governments deliberately switched off their own websites. In the UK, 32 government services went dark, and four more were partially down. Germany, France, Belgium, Finland, the Netherlands, and Australia pulled sites too. Cloudflare has since recorded millions of attempts to exploit the flaw.
The underlying bugs had sat in PHP for decades. Proving they were exploitable needed a chain at the edge of what humans could manage. Frontier AI models lowered that barrier. The NCSC called the scale unprecedented and likely not the last. News channels are headlining, “AI changed the economics of exploitation.”
Access the Best Practices Guide: AI Threat Resilience in the Age of Mythos. Explore 11 prioritized actions to prepare for machine-speed attacks.
But, as I write this blog, the shutdowns remain costlier than the real impact. No known cyberattack has openly exploited this vulnerability.
Did the world manage to patch on time?
Or did the affected not report it yet?
Or were web servers not a fancy enough target for modern-day attackers?
One thing is sure. We still do not know how to keep businesses operational during such emergencies. Almost everyone has not defined a minimum viable digital enterprise.
The Issue
PHP2Shell is a pair of unauthenticated remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS v4.0. In plain terms, an attacker can run their own code on your web server without logging in.
- CVE-2026-109618 (out-of-memory corruption): when PHP runs out of memory mid-request, cleanup can treat half-built internal data as valid.
- CVE-2026-109619 (stale global state): state from one request can survive after its memory is freed, and the next request on the same worker can use it.
Every PHP installation serving web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The flaws reach back to PHP 5.4. PHP rates mod_php as highest risk, because a single request can trigger the attack before any application code runs. Your secure coding practices do not help here.
The fix is PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, released on October 21. PHP says no configuration change fully closes the hole. Worse, technical details leaked before the embargo lifted, so attackers had a head start.
Three things stand out for me.
PHP hides inside things you don’t think of as PHP. Palo Alto Networks confirmed all versions of PAN-OS and Panorama are affected. Fortinet is checking 12 products and Cisco 31. Control panels like cPanel and Plesk also ship PHP on someone else’s schedule.
Your logs may not tell you. Exploitation happens below the application layer, so application logs may record little. Confirmed indicators of compromise remain limited.
WAFs are a speed bump, not a wall. Attackers are already adapting payloads to evade WAF rules. Any internet-facing PHP server unpatched after October 20 should be treated as potentially exposed.
The Real-World Impact: Who Paid for the Shutdowns
As of October 22, officials in Germany, the Netherlands, Japan, and the UK report no confirmed break-ins. The damage so far came from the defense itself: services switched off to stay safe. That still hit citizens, customers, and revenue.
Sources: TNW, UptimeRobot, BigGo Finance, Wikipedia.
Zero hospital outages.
But the social cost is real.
When a country’s national login goes dark, people cannot file, claim or apply.
UptimeRobot saw failed website connections jump to about 1.3 million an hour, against 430,000 normally. Downtime alerts from Europe rose about 20 times. They were still 30% above normal the next morning. Patching itself caused delays, as php.net and a major Ubuntu package repository buckled under the load.
No one has published a dollar figure yet. The real costs today are hours of lost online transactions, emergency engineering time, and customer goodwill. For banks and retailers, every offline hour means sales and service that do not happen.
My Recommendations
Patch first. That part is not debatable. But if your response ends at the patch, you have only closed the front door after the guests may have walked in.
Start your investigation from October 17, not October 21. Amazon was explicit that compromise may predate the advisory. Any PHP server that was internet-facing in that window gets a compromise assessment, not just an update. Look for new web shells, unexpected child processes from the PHP worker, and outbound connections the server has never made before.
Hunt for shadow PHP. Your web team knows about the website. Do they know about the firewall management console, the hosting panel, the vendor-supplied HR portal, or the old marketing microsite? Ask every vendor for a written PHP2Shell statement.
Contain what you cannot patch today. Legacy branches like PHP 8.1 and older no longer get upstream fixes. Appliances wait on vendor releases. If you cannot patch it, isolate it. Block its outbound internet access, restrict what it can talk to internally, and put it behind access controls. If that is not possible, follow the NCSC’s advice and switch it off.
Stop treating the web tier as trusted. A web server that can reach your database, your file shares, and your domain controllers turns one RCE into a full breach. This is exactly where microsegmentation earns its keep. The attacker may land, but they should land in a room with no other doors.
Rewrite your patch SLA for the AI era. A 30-day window for critical internet-facing flaws is now fiction. Exploits arrived hours after disclosure, and in this case, days before it.
Document your minimum viable digital enterprise (MVDE). Do not wait for the next PHP vulnerability. Decide what you must keep operational under an active cyber threat situation. Microsegment that part. Leverage your EDR. Build operational processes around the MVDE.
Watch Video | See how an AI-assisted attack completes its attack chain in 63 seconds, while ColorTokens blocks unauthorized access paths in the protected environment.
Questions for the Next Board Meeting
Boards do not need to understand memory corruption. They do need to ask questions that expose whether the organization is ready.
- Were we exposed to PHP2Shell, and how do we know? Does the answer cover vendor appliances and third-party hosted sites?
- How many hours did it take us to patch every affected internet-facing system, and what is our target?
- Did we investigate for compromise back to October 17, or did we only patch?
- If one of our web servers were taken over today, what else could the attacker reach?
- Who has the authority to take a customer-facing service offline, and have we rehearsed that decision?
- AI is now finding and weaponizing decades-old flaws faster than vendors can fix them. How are our security budget and operating model changing to match that pace?
PHP2Shell is a preview of the new normal.
AI will keep pulling old, deep flaws to the surface, and exploits will arrive faster than patches.
We cannot out-patch that curve on our own.
What we can do is make sure that when an attacker lands, the damage stops at the first server.
Patch fast, assume breach, and contain by design to strengthen breach readiness.
To explore how ColorTokens can help contain attacks and keep critical services running, connect with us.
