AI found the bug in a week. Fixing it took two months.

The busiest people this week were probably the ones who look after PHP servers.

On October 21, PHP pushed out emergency releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. Both score 9.2 on CVSS v4. Every version from PHP 5.4 (released in 2012) through 8.5 is affected, and on common software such as WordPress and Drupal they allow remote code execution without logging in. By W3Techs’ count, about 69% of websites whose server-side language can be identified run PHP.

Over the next two days Finland took all of its government’s public-facing services offline, every French Interior Ministry website went dark, the Dutch government portal Overheid.nl came down for a while, and Wikimedia shut a batch of services. The NSA’s advice was blunt: if you cannot upgrade right away, take the site offline.

This site is plain static pages served straight from nginx, with no PHP, so I slept through it. But the episode is worth a closer look. Here was a bug, found with AI help, that reached most of the internet, and AI shows up at every step from discovery to exploitation.

Discovery: from “suspicious” to “exploitable”

The root cause is not exotic. When PHP hits a fatal error such as running out of memory while handling a request, it jumps out and ends the request, and some internal state is never cleaned up. The next request reuses that leftover state and can end up reading memory it should not see, or overwriting it.

People had noticed parts of this before. According to the timeline compiled on Wikipedia, a PHP core developer ran into one of the out-of-memory handling problems during an audit in 2024. The team could not agree on a fix, nobody had a working exploit, and the issue was set aside.

This August the security firm Calif, funded by OpenAI, audited PHP’s source and found the first bug with help from GPT-5.6 Sol. A few weeks later Wiz found the same problems independently, using its own Wiz Atlas together with Gemini 4 Argon and GPT-5.6 Sol. Wiz’s timeline is precise: found on August 19, unauthenticated remote code execution on Drupal on the 20th, on WordPress on the 21st. In their words, a single researcher did in about a week what would previously have taken a world-class team months.

That is the real change. Spotting something that looks wrong has never been the hard part. The hard part is proving it can be exploited: debugging against different PHP versions, configurations and memory layouts, failing and adjusting over and over. That used to take a handful of very rare people grinding for weeks, which is why so many “theoretical” problems stayed theoretical. Now a model can take on most of the debugging and iteration, and the cost of proof has collapsed.

Calif itself is restrained about it. They used only generally available models and no special tooling, and say what mattered most was knowing PHP’s history: “No model is simply capable of unearthing ‘all bugs’ with simple prompts. At least for now.”

The fix: same speed as ever

Discovery got faster. The fix did not.

By Wiz’s timeline, they reported the bugs to the PHP security team on August 24. PHP acknowledged them and began a coordinated fix on September 21, 28 days later, and the patch shipped another 30 days after that.

I do not think anyone was negligent. The Guardian reports that the PHP Foundation has just 13 full- and part-time employees, looking after the foundation of most of the web. And this kind of fix cannot be rushed. It touches error-handling machinery designed more than a decade ago, has to land on several release branches, and has to be coordinated with Cloudflare, AWS, Microsoft, Google and others so their protections are ready on release day, with US agencies including CISA in the loop. The whole process was built for human speed, where months from report to patch is normal.

The trouble is that it is no longer up against human speed.

The window: from days to hours

The plan was to publish the patch at 14:00 UTC on October 21. The plan did not survive.

In its MadPot honeypots, AWS saw the first exploitation attempt on October 17, from an IP on an anonymization network, four days before disclosure. How the attacker got the details early is still unknown. On October 20 the news leaked on Hacker News, watchTowr confirmed the bugs before any patch existed, and Calif accidentally released a video demonstrating the exploit. The security firm Sansec predicted “mass attacks to start within 15 minutes of the release.”

At 03:02 UTC on the 21st, Cloudflare switched on temporary protection rules for all customers. The patch shipped that afternoon, several exploits were circulating within hours, and AWS sensors were being hit almost immediately. Palo Alto’s Unit 42 counted more than 22.6 million potentially exposed PHP instances.

AWS partly attributes the shrinking gap between patch and attack to AI-assisted analysis: more people can now take a patch or an advisory and turn it into a working exploit quickly. One line in their advice to defenders is, I think, the thing to remember from all this: for critical internet-facing vulnerabilities, measure patching and mitigation in hours, not days.

Attackers have agents too

On October 23, Unit 42 added a detail that bothers me more than the bug itself.

In one incident they handled, the victim was a European government body. After getting in through PHP2Shell, the attackers used an AI agent attack platform for everything that followed. Within two hours of the initial break-in they had password hashes and multi-factor authentication secrets, then set up an NTLM relay tunnel into Active Directory and started trying to escalate to Domain Admin.

Unit 42 recognized the agent from its command history. Commands ran in batches, and each block of output was preceded by markers such as “==SHELLUSER==” and “==PASSWD==”. Those are not for a human to read; they make the output easy for a model to parse. The tasks were short and ran one after another, and on failure it switched approach immediately instead of pausing to think.

It took me back to my years on call. Going from a foothold to the domain controller used to take days or weeks, and defenders could count on some time to notice and respond. If that shrinks to a couple of hours and no one even has to sit at the keyboard, the default assumption of “we’ll deal with it once we spot it” stops holding.

What it means for people who build systems

Defenders are using AI too. On patch day OpenAI announced “Patch the Planet”, putting up $1 billion to subsidize access to its Daybreak security platform for under-resourced defenders, and said it expects similar findings to “increase sharply” in the coming months. Wiz is using Gemini for attack detection and patch validation. Both sides have much the same models. What separates them is, again, the system: who can wire the models into their own processes faster.

Looking at how this played out, here is what I think any team can do now:

• Treat your release pipeline as security infrastructure. Whether you can push a patch to every machine within a few hours, with one-step rollback if it goes wrong, depends on whether everyday builds and releases are automated. On a normal day that is an efficiency question. On a day like October 21 it is a security question.
• Know what you run. Of those 22.6 million exposed instances, how many are old sites, test boxes and internal tools their owners have forgotten? Without an asset inventory, no patch is fast enough to reach them.
• Go static where you can. If a page does not need code running on the server, do not run any. The code with the smallest attack surface is the code that does not exist.
• Detect behavior, not just signatures. AWS makes the same point: do not rely only on signatures for a particular CVE. A PHP process suddenly running shell commands, or worker processes restarting over and over, is worth an alert whatever the cause. The way agents operate also yields new signals to detect.
• Start investigating from the earliest date. Exploitation attempts came four days before disclosure. Search your logs from October 17 or earlier, not from patch day.

Closing

We used to assume there was some time between a bug being found, being proven and being exploited, and our patching processes were built on that time. PHP2Shell squeezed it out. AI made proving a bug cheap and turning a patch into a weapon cheap, while the fixing side is still a dozen or so people working on a timescale of months.

OpenAI says there will be many more findings like this, and I believe it. Over the next few years, how open-source infrastructure is maintained and how vulnerabilities are disclosed will probably have to be redesigned for the new speed. Until then, the most any team can do is make its own path from “we found a problem” to “the fix is live” as short as possible.

---

References

• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 2026-10-21
• CJ Moses, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog, 2026-10-21
• Palo Alto Networks Unit 42, Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619, updated 2026-10-23
• The Next Web, PHP rushes out emergency patches for two critical bugs AI found first, October 2026
• Wikipedia, PHP2Shell (timeline, and The Guardian’s reporting on PHP Foundation staffing)