AI Found Two Critical Bugs in PHP, and Websites Went Offline to Fix Them

On Wednesday a lot of websites around the world went offline on purpose.

They hadn't been hacked. Their owners were patching PHP, the language runtime underneath WordPress, Drupal, Joomla, Magento, Laravel and a big share of the rest of the web. Reuters reported that government websites in Europe and elsewhere went dark after the disclosure, and plenty of smaller sites switched to a maintenance page for a few hours.

I should say up front: I've never written PHP, and I haven't tested anything here. This post is me reading the advisories and the coverage as a curious developer. What pulled me into this story isn't PHP. It's how the bugs were found: by security researchers working with frontier AI models.

What happened, in order

This is the timeline as PHP, Cloudflare and the press report it.

• Tuesday, October 20. The PHP security team posted advance notice of a critical security release for Wednesday at 14:00 UTC, fixing two vulnerabilities rated CVSS v4.0 9.2. Details started leaking that day. CyberScoop reports an exploit-chain video spread online overnight, and that the release had originally been planned for Thursday under embargo before PHP moved it up a day.
• Wednesday, 03:02 UTC. Cloudflare says it switched on firewall rules for all its customers, including the free plan, about nine hours before the official disclosure, and that it saw attack traffic and attackers tweaking their payloads to get around the rules.
• Wednesday, October 21. PHP shipped fixed versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) with a blunt line: "There are no complete mitigations, updating is the only safe choice."
• Friday, October 23. PHP published an informational advisory for a third, separate issue, CVE-2026-115560, which it describes as an "unlikely" risk that needs an unusual configuration.

The two bugs, as PHP describes them

PHP's advisory explains each one in two sentences. Here's my plain-English reading of them, as someone outside the PHP world.

• CVE-2026-109618, "RCE via OOM corruption." PHP can run out of memory partway through setting up a request, while its internal data is only half built, and the cleanup code afterwards treats that half-built data as valid.
• CVE-2026-109619, "RCE via stale global state." PHP reuses the same worker process for many requests. Some state from one request can survive after its memory has been freed, and the next request on that worker can pick it up.

"RCE" means remote code execution: an attacker running their own code on the server. Two things in the advisory explain why people reacted so strongly. It says the risk covers "all PHP installations serving web requests", and that on one common setup (Apache with mod_php) there's "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." No login needed, and the website's own code never gets a say.

The part I can't stop thinking about: AI found them

According to OpenAI, the bugs came out of its Patch the Planet initiative. The security firm Calif found a critical flaw using GPT-5.6 Sol, and Wiz independently found and reported both. Wiz says it used GPT-5.6 Sol, Google's Gemini 4 Argon and its own tool, Wiz Atlas. PHP's own maintainers wrote and shipped the fixes, with OpenAI, Wiz, Cloudflare and others helping coordinate.

A few lines from the coverage stuck with me:

• OpenAI: "To our knowledge, frontier AI found these vulnerabilities before attackers did." It calls that head start a "Defender's Window", and says it expects "similar findings to increase sharply in the coming months."
• Wiz, quoted by Krebs on Security, says these were long-standing flaws that were hard to exploit, and that "frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."

What I find remarkable is that both statements are true at once. The same capability that let defenders get there first also makes the next bug cheaper for everyone to find, including the people we'd rather didn't. Microsoft hinted at this in July, when it warned that AI-driven bug-finding would mean bigger Patch Tuesdays from now on (I mentioned it in The Decode #002). This week is what that looks like when it lands on something a huge part of the web depends on.

I use AI agents every day to build apps, and my mental model of them is "a very fast pair programmer." Reading this, I had to stretch that model. These tools are now good enough to dig into a decades-old, heavily used runtime and find bugs that people hadn't. That's exciting and a little unnerving at the same time.

What's still unclear

The reporting on whether anyone was actually breached is mixed, so here's both sides:

• Attack attempts are real. Cloudflare saw attack traffic. watchTowr says its honeypots saw exploitation on the 21st. The Hacker News, citing Amazon, reports an attempt on Amazon's honeypots on October 17, four days before disclosure.
• Confirmed break-ins are thin so far. CISA said on the 21st it hadn't observed exploitation. Canada's Cyber Centre, updated on the 23rd, says a proof of concept exists but no active exploitation has been identified, and notes this "can change quickly." Several researchers say a reliable exploit is harder to build than the headlines suggest.

Most of Wednesday's downtime was precaution. As Malwarebytes points out, a site in maintenance mode doesn't mean it was breached.

Other things that surprised me

• Updating your app isn't updating the runtime. Malwarebytes put it simply: "Updating WordPress or its plugins does not update PHP." Cloudflare says the same. The bug lives in the layer underneath, which is often your host's job, not yours.
• Old versions are most of the exposure. CyberScoop reports a VirusTotal count of about 758,000 servers on PHP versions that no longer get updates, against about 272,000 on supported ones. The patch shipped within hours, but for most of those servers "just update" means an overdue upgrade first.
• Firewalls bought time, not a fix. Cloudflare and AWS both shipped protective rules quickly, and both say plainly that patching PHP is the real fix.

If you do have a PHP site, the place to start is PHP's own advisory, or your hosting provider if they manage PHP for you. I'm not the person to give PHP advice.

What I'm watching

Whether OpenAI's "increase sharply" prediction turns into more Wednesdays like this one, and how other runtimes and big open-source projects get ready for AI-found bugs arriving faster than before.

Sources

PHP project

• PHP, Upcoming Critical PHP Security Release (Oct 20, 2026)
• PHP, Security advisory: Critical remote code execution vulnerabilities, update now (Oct 21, 2026)
• PHP, Informational advisory: Session upload progress (CVE-2026-115560) (Oct 23, 2026)

How it was found

• OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities (Oct 21, 2026)
• Krebs on Security, Widespread PHP Flaw May Cause Many Site Outages Today (Oct 21, 2026)
• CyberScoop, PHP releases emergency fixes for 2 critical vulnerabilities (Oct 21, 2026)

Attacks and protections

• Cloudflare, Cloudflare deploys protections against php2shell vulnerability (Oct 21, updated Oct 23, 2026)
• AWS Security Blog, Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (Oct 21, 2026)
• Canadian Centre for Cyber Security, AL26-026: Critical vulnerabilities impacting PHP (Oct 21, updated Oct 23, 2026)
• The Hacker News, PHP warns of another unpatched RCE risk two days after emergency PHP2Shell patches (Oct 23, 2026)

Outages

• Malwarebytes, PHP2Shell: Why many websites had to go offline (Oct 2026)