The good side found PHP2Shell first. Next time it might not.

For anyone whose company website runs on PHP, WordPress included. What AI found this week, why it reaches so far, and what it would have looked like if attackers had found it first and told nobody.

On Wednesday 21 October 2026 the PHP project shipped emergency fixes for two flaws in the language that runs most of the web. Both were found with the help of AI models, by people who reported them in private and gave the maintainers two months to fix them. The flaws weren't new. Parts of the problem had been noticed in 2004, 2019 and 2024, and each time it looked too hard to use. AI made it easy. This week the people with the AI were on the defenders' side. But the same models are available to the other side, and an attacker who finds the next one won't send anybody an email.

What happened this week

On 20 October the identifiers of two unreleased PHP vulnerabilities started circulating on Hacker News and social media. The PHP security team had planned to publish fixes on 22 October. It moved the release forward a day and gave advance notice that afternoon, saying it might go earlier still (Tenable, a vendor that sells vulnerability scanners). The fixes landed on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The project's note was blunt: "There are no complete mitigations, updating is the only safe choice" (PHP).

The reason for the alarm is where the flaws live. PHP is the language behind WordPress, Drupal, Joomla, Magento and Laravel, and W3Techs counts it on 69.3% of websites whose server-side language is known (via Tenable). Most security holes you read about are in a plugin or one company's product. Not these. They're in the engine that runs all of them. Wiz, which found them independently and sells cloud security tools, says the problem doesn't depend on the website's own code: even a test page that only prints Hello World can be attacked on an affected version (Wiz). Cloudflare, which sells the web firewall that many of those sites sit behind, puts it plainly for site owners: "updating website code or a plugin(s) alone does not fix these vulnerabilities" (Cloudflare). Wiz traces the affected code back to PHP 5.4, which covers more than a decade of releases.

Old versions are the bigger worry. Among servers that show their PHP version, about 758,000 run branches from 5.4 to 8.1, against 272,000 on supported branches, according to VirusTotal figures reported by CyberScoop. Those older branches no longer get updates from the PHP project. Because of the severity, the PHP team made an exception and published minimal fixes for 7.4, 8.0 and 8.1. There's nothing for PHP 5.

The response was fast and a little nervous. The UK's NCSC told organisations that "Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated" (NCSC). Some did. Government agencies in the Netherlands and Finland took websites offline as a precaution, Reuters reported (via Fortune). Cloudflare's chief executive, Matthew Prince, told Fortune the company saw tens of thousands of attack attempts within 45 minutes of the news getting out. By the evening of 21 October it was millions (Fortune). How many of those attempts actually got in wasn't clear when we wrote this on 22 October. CISA said that afternoon that it hadn't observed exploitation, and Huntress, which watches customers' servers, hadn't confirmed a successful break-in either (CyberScoop).

Who found it, and how

The first flaw was found in August by a small security research firm that OpenAI had invited into Patch the Planet, its programme for finding and fixing holes in widely used open-source software. The firm used OpenAI's GPT-5.6 Sol, a model OpenAI has so far released only to a small group of companies (The Hacker News). OpenAI then led the coordination with PHP's maintainers, Cloudflare and US government agencies (OpenAI). OpenAI, of course, has a model to sell, and this is a good story for it.

A few weeks later Wiz found the same flaws on its own. Its timeline starts on 19 August, when its researchers spotted the first bug using Google's Gemini 4 Argon, GPT-5.6 Sol and Wiz's own AI tool, Atlas. By 21 August they had a working attack against WordPress, and on 24 August they reported everything to PHP (Wiz). Wiz is owned by Google, so it has its own reasons to credit Gemini, and it does. Its summary of what the models changed is the line worth remembering: "a single researcher completed in a week what previously would have taken a world-class team months of work".

Then came the part nobody saw. It took two months. The maintainers wrote a fix while web firewall vendors, cloud providers and Linux distributions prepared protections in private. Cloudflare switched its rules on for every customer, free accounts included, at 03:02 UTC on 21 October, about nine hours before the details went public (Cloudflare). OpenAI's description of the result: "To our knowledge, frontier AI found these vulnerabilities before attackers did" (CyberScoop). It calls the gap a "Defender's Window".

"Wasn't considered significant at the time"

The most interesting fact about PHP2Shell is how long the bug family had been in plain sight. In July 2004 a researcher named Stefan Esser reported that PHP could be stopped mid-request at a point where stopping wasn't safe. He warned it could be abused to run code on a server (Bugtraq). In 2019 someone filed a security bug showing that oversized form uploads could crash PHP (PHP bug 78876). OpenAI's president, Greg Brockman, wrote this week that a limited version of PHP2Shell itself "had been discovered in 2024 and wasn't considered significant at the time" (quoted by Fortune).

So people had seen the warning signs three times. What they didn't have was the patience to turn them into a working attack, because that's slow, fiddly work that has to be redone for each server set-up. Wiz says demonstrating the flaws "required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve" (Wiz). The models did that part. They tried, failed, adjusted and tried again, for hours, at the cost of computing time.

That's the shift. It's less dramatic than "AI sees what humans can't". We'd put it this way: AI didn't find a secret. It made an old, known and tedious problem worth the effort. Wiz says the same in fewer words: "This changes the economics of both discovery and exploitation." For years a lot of software has been protected by nothing more than the fact that attacking it was too much bother. That protection is wearing out, and it wears out for both sides at the same rate.

"Before a patch was made publicly available"

Run the same story with one change. Just one. The person who finds the flaw in August works for a criminal group, or for a company that sells hacking tools to governments.

There's no email to the PHP security team. There's no two-month window, no firewall rules switched on in the middle of the night, no patch on 21 October. The flaw goes into a toolkit and gets used one target at a time, because a loud mass attack would get it noticed and fixed. Nobody issues a CVE. Website owners have nothing to update because, as far as the world knows, there's nothing wrong.

That isn't a thought experiment. Google's Threat Intelligence Group, part of a company that also sells security products, counts these every year. It defines a zero-day as "a vulnerability that was maliciously exploited in the wild before a patch was made publicly available", and it tracked 90 of them in 2025, almost half in software that businesses run (Google). For the first time it attributed more of them to commercial surveillance vendors, firms that sell exploits to their customers, than to traditional state spy agencies. Those are only the ones that got caught. And Google's own forecast for 2026 is the reverse of this week's good news: "We expect adversaries will utilize AI to automate and scale attacks by accelerating reconnaissance, vulnerability discovery, and exploit development."

There's a detail from this week that should make anyone pause. Amazon says one of its decoy servers saw a PHP2Shell attack attempt on 17 October, four days before the fixes were public. It doesn't know how the attacker got the information (Tenable, reporting Amazon). Maybe it leaked from the disclosure process. Maybe someone else found it independently, the way the defenders did. And either way, the defenders' window wasn't completely shut to the other side.

The models that found PHP2Shell are, for now, kept behind access controls. Not every useful model is, and as we described in Part 2 of our AI history, attackers were already running parts of their operations through AI agents in 2025. Expect the next flaw of this size to be found by someone using AI. Whether you hear about it from a patch notice or from your own logs depends on who that someone is.

What we'd do if this were our website

This part is only for companies that run something on PHP. If that's you, here's what we'd do, in the order we'd do it.

First we'd find out where PHP actually lives. The main website, yes, and also the old campaign microsite, the customer portal, the intranet, and the internal tool a contractor built years ago that nobody has opened since. That last kind is the easiest to forget, and an attacker doesn't care which door they come through. The NCSC also asks organisations to check appliances and services that bundle PHP inside them, so we'd put the same question to our suppliers.

Then we'd put a name next to each one. If a hosting company runs PHP for us, we'd ask them in writing, today, whether they've installed a fixed version or their own patched build, and when. Some hosts protected customers before the release. We wouldn't assume ours was one of them until they told us.

Anything we couldn't confirm as patched by the end of the day, we'd take offline. That's the NCSC's advice as well, and a site that's down for a day costs less than one that's been taken over. We'd leave the web firewall switched on, but we wouldn't count it as the fix. Cloudflare says as much about its own rules.

Old versions would get a plan of their own. This week's emergency fixes for out-of-support branches were an exception, and nobody has promised another. If one of our sites still ran on such a branch, we'd book its upgrade, or its retirement, now, while everyone is paying attention.

Last, we'd look backwards. Amazon advises starting any investigation from the day its decoys saw the first attempt, not from disclosure day. We'd ask whoever watches our servers to check for unusual errors and crashes since then, and we'd want that answer in writing too.

The window won't always be open

This week went about as well as a flaw this size can go. The finders reported it, the maintainers fixed it, the big infrastructure companies shielded their customers early, and governments told people what to do within a day. That was the good version. It still wasn't calm.

OpenAI says it expects "similar findings to increase sharply in the coming months" (CyberScoop). We think that's right, and it cuts both ways. The defenders' window only exists when defenders get there first. When they don't, the only thing that helps is how quickly you can find your own systems and fix them, so it's worth practising that now, while this one is fresh.