Every website is a house built on a foundation the owner never sees. You pick the paint and the furniture. You argue about the front door. Under all of it sits a slab somebody poured years ago, and for most of the web that slab is PHP.
This week the world found out there’s been a crack in that slab since 2012. A researcher reported the first sign of it back in 2004, and it sat there because breaking through it took more patience than any attacker had. Then somebody pointed an AI model at it, and the AI found a way through in about two weeks.
I spent 33 years in technology, a lot of it in cybersecurity, and my own business runs on a WordPress site. WordPress is written in PHP. So are the 70-odd plugins I’ve built for it. This one hits close to home.
Your author website, WordPress and your plugins all rest on PHP. The crack sat in the foundation for 14 years.
What is the PHP2Shell vulnerability?
PHP2Shell is the name given to two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. Government agencies described both as remote code execution that needs no login. An attacker who never signs in can make your server run their code. From there they can read passwords, copy the database, plant malware or use your server as a door into the rest of the network.
The flaw lives in how PHP cleans up after a request gets cut off. CNN’s David Goldman compared it to a restaurant kitchen. Bury the chef in orders until she walks out mid-shift, and the next chef serves food off the dirty pans she left behind. When PHP runs out of memory at just the wrong moment, it leaves stale data lying around, and the next request can be tricked into using it.
PHP runs about 70% of the websites that use a server-side language. WordPress alone powers around 40% of all websites. Palo Alto Networks counted 22.6 million potentially vulnerable PHP instances.
Why did a PHP flaw go unexploited for 14 years?
Because exploiting it was miserable work. Stefan Esser warned about the weakness in July 2004. Another researcher found a related problem in 2020, and the PHP maintainers issued a partial fix. A similar flaw turned up in 2024 and was left alone.
Tedium was the lock, and AI doesn’t get bored.
To break in, an attacker had to crash the server’s memory at one exact instant and slip past PHP’s safety limits. Nobody bothered. One security CEO called it “security by exhaustion”: the door was unlocked, but it took so long to open that nobody tried.
Tedium was the lock, and AI doesn’t get bored.
On July 30, 2026, researchers at the security company Calif, working with OpenAI’s Patch the Planet program, pointed an AI model at PHP. OpenAI says the model was GPT-5.6 Sol. On August 1 it first crashed PHP. By mid-August it had a working attack, and it reported a second flaw on August 21. The cloud security firm Wiz found and reported the flaws on its own. The researchers said they used AI tools anyone can get.
What happened after the PHP2Shell patch was released?
Attackers moved before most site owners did. The PHP project shipped its fix on October 21. Word had leaked ahead of the release, and Amazon Web Services said it saw exploit attempts before the official disclosure.
Cloudflare reported tens of thousands of attack attempts within 45 minutes of the news and millions by the next morning. Government agencies in the Netherlands and Finland took websites offline as a precaution. Proof-of-concept code started circulating almost immediately.
It didn’t stop with the patch. On October 23 the PHP project warned about a third flaw, CVE-2026-115560, in the same session upload feature, and the October 21 releases don’t fix it. It needs an unusual setup to work, and PHP’s interim advice is to turn session upload progress off until the next release. By October 26 a researcher’s honeypot had recorded a confirmed takeover of an unpatched server through the original flaws.
That’s the new pattern. A patch tells the whole world where the hole is. Twenty years ago you had weeks before anyone turned a patch into a working attack. Now you have hours, and the same AI that found the flaw can help an attacker weaponize the fix.
A 14-year-old PHP flaw was safe because exploiting it was boring. AI doesn’t get bored. Patch your site this week.Share on X
Why does a security patch lead to more attacks at first?
Because a patch is a map. The moment the fix ships, anyone can compare the old code with the new code and see exactly what changed. That shows them where the hole was. Attackers used to need days or weeks to turn that comparison into a working attack. With AI doing the tedious part, it takes hours.
So the most dangerous window is the stretch between the patch going public and the patch landing on your server. For PHP2Shell, that window started before the official release, because details leaked.
Does that mean patches are bad? No. It means a patch you haven’t installed is worse than no news at all, since the attackers now know about the hole and you’re still sitting in it.
Who maintains the code an author website depends on?
Mostly people you’ll never meet. PHP is an open-source project. The PHP Foundation paid 11 developers to work on it going into 2026, on about $730,000 in donations for the year, and volunteers fill in the rest. WordPress is open source too. Your theme and plugins come from companies, solo developers and hobbyists, and some of them stopped paying attention years ago.
That system has worked surprisingly well for decades. It also means the foundation under 70% of the web had a known weak spot that nobody had the time or money to fully fix. Effort kept it safe, and money never did.
PHP isn’t the bottom, either.
It runs on an operating system, and on most web servers that’s Linux. Linux leans on small open-source libraries for compression and encryption. Some of those have been kept up by one or two people. When the Heartbleed bug hit in 2014, OpenSSL, the encryption library behind a huge share of secure websites, had about one full-time developer. In 2024 a stranger spent two years earning the trust of the volunteer who maintained xz Utils, a compression tool, and nearly slipped a backdoor into Linux through it.
Under all of that sits DNS, the internet’s address book. It turns a name like thewritingking.com into a server your browser can find. DNS is run by large organizations, not a lone volunteer, but everything above it stops working when it does.
The people holding the money aren’t paying for much of this. I made that case in billions for AI, pennies for the plumbing.
I’m in that chain myself. Most of the plugins on my site are ones I built, and this month I had every one of them put through a security review. Fixes are still going in. I wanted to find the small weaknesses nobody had bothered to test before somebody else’s AI found them for me.
Is my WordPress author website affected by PHP2Shell?
If your site runs on WordPress, it runs on PHP, so the answer depends on your host and your PHP version. Most authors are on managed hosting, where the host updates PHP for you. Your job is to confirm they did it.
The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Anything older on those branches is still exposed, and for PHP 8.1 and earlier the PHP project published backport patches but no official releases, so a fixed build has to come from your host or your Linux distribution. If your control panel shows a lower number, ask your host whether they backported the fix, because some hosts patch without changing the version.
Mine is on SiteGround’s GoGeek plan, running PHP 8.4, with Cloudflare Pro in front of it. That setup is about as boring as hosting gets, and boring is what I want. Even so, I don’t assume. A host that patches most servers in a day can still miss an old one, and a site pinned to an outdated PHP version won’t get the fix at all.
The security company CrowdStrike pointed out that lots of servers still run old PHP versions. It also said the patch almost certainly didn’t fix every problem PHP has. Few sites can realistically leave PHP. You’d be rebuilding the site from scratch.
| Check | How to do it | Why it matters |
|---|---|---|
| PHP version | Look in your hosting control panel or under Tools, Site Health in WordPress | An outdated version won’t get the fix |
| Host’s patch status | Read your host’s status page or open a support ticket and ask | On managed hosting, the host applies the PHP update |
| Firewall | Turn on a web application firewall, like Cloudflare’s managed rules | Cloudflare shipped PHP2Shell rules as a stopgap |
| Backups | Confirm a recent backup exists somewhere other than the server | If someone got in before the patch, you need a clean copy |
| Error logs and odd files | Scan the PHP error log and run your host’s malware scanner | Strange errors or new files can be the first sign of trouble |
| Unused plugins and themes | Delete anything you aren’t using | Less code on the server means fewer places to hide |
How should author websites handle security now that AI finds flaws faster?
Assume the clock runs faster than it used to. Security people have relied on effort for a long time without saying so. Plenty of known weaknesses never got exploited because the payoff wasn’t worth the work. AI just cut the work, so the old excuse for putting off an update (“nobody would bother”) is dead.
I’ve written that WordPress security is a posture, not a plugin. PHP2Shell shows why. No single tool would have saved you here. Layers do. On my own site, Cloudflare sits in front of everything and the login page is locked behind Cloudflare’s Zero Trust, so an attacker has to get through Cloudflare before WordPress even sees them. SiteGround’s scanner runs every night. About once a month I read the PHP error logs myself. None of that is exotic, and all of it adds up.
The other lesson is about the supply chain. You didn’t write PHP. You probably didn’t write WordPress or your plugins either. Your site depends on work done by people you’ll never meet, some of them volunteers, and a crack in any of it is a crack in your site. Fewer plugins, from developers who still maintain them, means fewer cracks.
And yes, the defenders have AI too. The same kind of model that found PHP2Shell found it for the people who fixed it. That race doesn’t end. Whoever patches faster wins it.
The people building these tools are saying the same thing. On October 22, Anthropic’s deputy chief information security officer, Jason Clinton, wrote that “as bad as things have gotten in the past 4 days, they are going to get a lot worse before they get better.” He told security leaders to go to their boards and ask for help with the basics, “Not for AI,” and said “we need to hold on for ~18 months.” He’d warned back in August that “the vulnerability tsunami is coming in just a few months.”
I agree with him about the basics. The defenses against this kind of attack have been known for decades: patch, back up, put a firewall in front, keep what matters off the open internet, and know what you’re running. None of it is glamorous. All of it works. An author website needs the small version of that list, and it needs it this week.
If you’re picking a host, pick one that manages PHP updates for you and patches fast. I run my business on SiteGround for that reason.
My take
PHP2Shell didn’t scare me. The 14 years did. A known flaw sat in the foundation of most of the web because breaking in was boring, and boredom was never a security control. AI ended that excuse in a couple of weeks. If your site runs WordPress, confirm the patch this week, keep a firewall in front of it, and stop putting off updates because nobody would bother. Somebody’s machine will bother.
What to do about PHP2Shell this week
Log in to your hosting account and find your PHP version. Ask your host whether the October 21 security release is on your server, and get the answer in writing. Turn on your firewall rules. Check that you have a backup you could restore from today. Then delete the plugins you stopped using two years ago.
The Cybersecurity Hub has the rest of my security articles, including the boring security work that keeps you safe. If you’d rather hand your author site to someone who watches this stuff, my WordPress service is the place to start. Nobody admires a foundation. Check yours anyway, before something heavy lands on the crack.
The same habits that protect a website protect a household, and this one covers them at home: which updates matter, and backups that survive whatever eats the originals.
