PHP2Shell, and why we need to rethink how the web gets served
On October 21, PHP shipped emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4). They can be exploited without logging in, and they can let an attacker run their own code on your web server. They affect every PHP version from 5.4 through 8.5, across the common server setups.
That's a big piece of the internet. PHP sits under WordPress, which sits under a huge share of small business websites. Wiz's write-up headlines the exposure at roughly 70% of the web. Reports differ on how far attacks have gotten, but Amazon says its honeypots logged an exploitation attempt four days before the public disclosure.
So security teams spent the week doing what is quickly becoming the norm: drop everything, patch, verify, monitor. And as AI-assisted bug hunting gets better, the cycle will only speed up. It is not sustainable.
What is all this tooling for?
Over the decades we've built the internet on tooling to make web content easy for humans to serve and manage. Server-side languages, databases, content management systems, plugin marketplaces, single-page web applications.
Let's remind ourselves what the point of all this tooling is. Priority one is to build compelling web pages for the people (and now the AI agents) reading them. Our tooling does that by boiling all this complexity down to HTML, CSS and, often, too much JavaScript. HTML is simple for AI agents to comprehend. It's about the easiest code a kid can learn. It is also very verbose. As a kid I dabbled with building simple web pages, hand coding everything. Spend a little time working out why a navigation bar looks one way on your home page but different on your photos page, and it's easy to understand why tools for dynamically serving this kind of content became necessary as the internet ramped up in the '90s. Static site generators helped later, but they still need a developer at the keyboard.
Each layer of that tooling brings its own code, and its own risk. The riskiest parts of a modern site are often the extras bolted on around it. In 2022, Patchstack found that 93% of WordPress vulnerabilities lived in plugins, not WordPress itself. JavaScript apps have the same problem one level down: a typical single-page app pulls in hundreds of npm packages, each maintained by someone you've never met. In September 2025, attackers phished a single maintainer and pushed malicious versions of 18 packages, including chalk and debug, with a combined 2.6 billion downloads a week. A week later, the Shai-Hulud worm began spreading itself through hundreds more. Every layer you add is someone else's code you're trusting, and someone else's bad day you inherit.
WordPress site
6 layers to keep patched
Patch
- Web server (host may handle)
- PHP runtime
- WordPress core
- Theme & plugins
- MySQL database
- Server operating system (host may handle)
Lock down
- Admin login
- Hosting account login
Single-page app with a backend
4 layers to keep patched
Patch
- npm packages & build tools
- API server
- Database
- Hosting / containers (host may handle)
Lock down
- User login / auth service
- Hosting & Git account logins
Static site
0 layers you patch
Patch
- Nothing. Your HTML and CSS files don't run, and Cloudflare patches its own network.
Lock down
- Cloudflare & Git account logins
The cost of security constantly sounding the alarm about the stack we built is going to force us to rethink how we serve web content.
The pivot: static files, maintained by agents
The arrival of AI agents that can write and debug code that would take me days or weeks on my own has been incredible to watch. We're all still working out the best way to use these agents, and one glaring issue I see is that we keep adapting them to the tooling we built to keep our sanity. In reality, today's agents can hold an entire small site in view at once and edit it reliably.
A static website is just files: HTML, CSS, images. No server-side code runs when someone visits. There's no database to steal, no admin login to brute-force, no plugin to forget about. PHP2Shell can't touch a site that doesn't run PHP. Neither can the next PHP bug, or the next plugin bug. Someone still patches servers, of course. It just isn't you; it's Cloudflare, whose entire business is running that infrastructure securely.
That matters more than it sounds. Cloudflare was part of the coordinated response to PHP2Shell, working alongside the PHP Foundation and Wiz, and started building protections in early October. Its firewall rules went live for every customer, free plan included, about nine hours before the flaws were made public. A small web agency managing multiple sites doesn't get that call. It finds out the same morning as everyone else, then starts patching. Our static sites didn't need those rules (there was no PHP to protect), but it highlights how useful it is having Cloudflare protect your network layer.
Static sites have always had the better security posture. The catch was always maintenance. Editing raw HTML is tedious for people, and that's the entire reason content management systems exist.
A change that used to need a developer, or a CMS login, can now be described in plain English and made by an agent, with a human reviewing and approving the result. Static files are hard for humans to maintain. Bots don't care.
And no, the agent doesn't become the new back door. It works on a separate preview copy of your site, every change is a reviewable diff, and nothing reaches your live site until a human approves the preview.
What this means for your business
My goal in this post is to plant a seed. For it to grow, you'll need to consider what you need from a website. A simple site that advertises your business and is updated infrequently is going to have a different migration path than something like an online retail platform.
If you're on managed WordPress hosting, your host likely patches PHP for you. That helps. But the plugins, the theme, the admin login and the monthly bill are still yours.
Static isn't for everyone. Online stores, customer logins and member areas need a real backend. Let's start considering how we can start better matching the right tool for the right site for all of our sanity moving forward.