AI found a 14-year-old hole under most of the web. The attackers showed up before the patch did.
At 7:43 in the morning, UTC, on October 21, 2026, Cloudflare reports attacks against a flaw in PHP. PHP is not an app. It is the programming language underneath WordPress, WooCommerce, Magento, Drupal and most of the websites on earth.
The fix ships at 14:00 UTC.
The attackers were more than six hours ahead of the patch. Amazon’s threat intelligence team says it caught an attempt in its decoy servers on October 17, four days before the flaw was public.
The two flaws, CVE-2026-109618 and CVE-2026-109619, got a nickname: PHP2Shell. An attacker who never logs in can run code on your server. According to OpenAI’s Greg Brockman, the bug had been sitting in PHP for 14 years.
How big is this
Big enough that “most of the internet” is not an exaggeration, but the numbers need reading carefully, because they count different things.
Websites. W3Techs measures PHP on 69.3% of websites whose server-side language is known. That is where the “70% of the internet” headlines come from. WordPress alone runs roughly 40% of all websites, according to Reuters. Essentially every version of PHP back to 5.4 carries at least one of the flaws.
Servers. A single server can host many websites, so server counts run far smaller than site counts, and every scanner counts differently:
- Palo Alto Networks identified 22.6 million potentially vulnerable instances.
- Censys sees about 2.57 million internet-facing hosts running PHP. Researcher Silas Cutler estimates over 1.3 million of them are likely vulnerable.
- On Shodan, Black Kite counted about 1.9 million internet-facing PHP hosts. Of the ones that reveal their version, about 1.37 million are in the affected range.
Those counts are a floor, not a ceiling. Black Kite notes that about four in five PHP servers hide their version number, and hiding the version doesn’t hide the flaw.
The long tail with no fix. Of the exposed servers that report a version, Black Kite found 72.5% running PHP releases that are past end of life. PHP released official fixes only for 8.2 through 8.5. Roughly a million servers are on versions that will never get an official patch. Their only real options are upgrade or unplug.
Commerce sits right in the middle of it. Calif confirmed attacks that need no login against WordPress, Drupal, Joomla and Magento. Black Kite’s scan alone found about 538,000 internet-facing WordPress hosts.
Who found it
Not one hacker in a basement. Several teams, independently, in the same few weeks of August 2026, and every one of them was working with AI.
A red-teaming firm called Calif found the first pieces on August 1 using OpenAI’s GPT-5.6 Sol. Wiz found its own path on August 19 using Google’s Gemini 4 Argon, GPT-5.6 Sol and its own tooling, and had working attacks against WordPress and Drupal within two days. Wiz’s summary of what the AI changed: “a single researcher completed in a week what previously would have taken a world-class team months of work.”
These were defenders. They reported it, PHP fixed it, and the industry coordinated a response.
But the same models are available to anyone with a credit card. OpenAI said it plainly: the capability that finds these flaws “can also help attackers rapidly develop offensive tools and exploits.”
This is the third one
PHP2Shell was not a one-off. It was the third time in five months that AI-assisted research broke something in the PHP world, and each time it went one layer deeper.
- May 2026, WordPress plugins. Researchers from TrendAI and CHT Security built an AI pipeline in three days and found more than 300 critical plugin zero-days in 72 hours of scanning, at roughly $20 per vulnerability. One of them, Steven Yu, warned that “any motivated attacker with a credit card can execute this.”
- July 17, 2026, WordPress itself. A flaw in WordPress core, found with GPT-5.6 Sol, was being exploited by multiple attackers within three days, according to Wiz. They planted backdoor plugins and webshells.
- October 21, 2026, the PHP language. Underneath all of it.
Plugin, then platform, then the language. The cost of finding a serious bug is collapsing, and it is collapsing for both sides at once.
What changed
I used to think of old code as safe code. Fourteen years in production without a problem is a kind of proof. Millions of sites, billions of requests, and it held.
That logic is gone. The bug was there the whole time. What kept it hidden was that reading fourteen years of a programming language’s internals, looking for the one way the pieces fail together, took a world-class team months. Nobody was paying for that.
With AI, one researcher did it in a week. The machine does most of the reading. Every old line of code you depend on is getting read, by somebody, for the first time.
27 minutes
On the afternoon of October 21, at 1:30 Eastern, one of our team members posts in our software channel:
“Major PHP vulnerability announced this morning. I’m working on updating our stuff.”
They do the patching with Claude.
At 1:57, they reply to their own message:
Two of the services they run: updated.
Twenty-seven minutes. The attackers had a six-hour head start on the patch, and a team working with AI closed its own window in under half an hour.
They were honest about the rest, too: “Other services will be more work for me to update the containers.” Nobody gets everything in 27 minutes. But the first two were closed the same afternoon the fix shipped.
That’s the gap. Not between good engineers and bad ones. Between teams that hand the reading, the inventory and the upgrade steps to AI, and teams that are still doing it by hand while the scanners hit their servers.
Why this lands on Amazon sellers
Amazon runs its own infrastructure. Your Seller Central account was not the thing exposed.
Everything around it was.
Your own sites. If your brand has a website beyond Amazon, look at what it runs on: a WooCommerce or Magento store, a WordPress blog, landing pages built to send outside traffic to the listing, the promo microsite from a launch years ago. All of that runs on PHP. Nobody has logged into some of it in a long time. That is exactly the server attackers are hoping for.
Every app holding your keys. When you authorize a tool in Seller Central, that company holds a token to your account. Repricers, review tools, analytics, inventory, accounting. Their servers are part of your attack surface, whatever language they are written in. Some of those apps you set up once and forgot.
Agencies carry it for every client. An agency running sites for many clients, and holding many clients’ Seller Central and advertising authorizations, is the blast radius. One forgotten server at the agency is a problem for every brand it serves.
What to do
- Put an AI agent on it first. Not a chatbot you ask questions, an agent that does the work: list every website, server and hosted tool your business touches, find what each one runs, and draft the upgrade steps for you to approve. The attackers are already using AI to read your code. Use it to read your own inventory.
- Find every PHP server you own, including the forgotten ones, and check the version. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older received no official release. A WordPress plugin update, a WooCommerce update or a Magento patch does not fix this. Only a PHP update does.
- If someone hosts it for you, get the answer in writing. Managed hosting is not patched until your host says it is. Ask which PHP version your site is running, and when it was updated.
- Clean out Seller Central’s app list. Go to Apps and Services, then Manage Your Apps. Disable anything you don’t actively use. Every authorization you remove is one fewer server you have to trust.
- If you’re an agency, answer your clients before they ask. An inventory of every client site, its PHP version, and every account authorization you hold is the most reassuring email you can send.
Who gets left behind
To be fair about this one: a day after disclosure, Sansec reported that the public exploits weren’t working against default PHP installs, and confirmed breaches were still limited. PHP2Shell may end up smaller than its first headlines.
That isn’t the point. The point is what it showed.
The same AI found the bug for the defenders and handed it to the attackers. Nobody has an edge in access. The only edge left is how you use it.
Asking a chatbot what PHP2Shell means doesn’t patch anything. The teams pulling ahead use AI agents: AI that doesn’t just answer, it does the work. It finds the servers, checks the versions, writes the upgrade, runs it, and comes back for a human to review. Those teams read faster, inventory faster and patch faster. They get ahead, and they stay ahead, because every one of these is practice for the next.
The teams that don’t are going to be patching by hand, six hours behind, against attackers who aren’t. They’re the ones who get left behind. And they’re the ones who get hacked.
The bug was there for fourteen years. The gap between the teams that use AI and the teams that don’t is going to open a lot faster than that.
