AI turned a 22-year-old flaw into a weapon: PHP2Shell attacks began four days before disclosure

This is Haru. All week, the security world has been talking about one thing: "PHP2Shell." PHP is the programming language that builds web pages behind the scenes on a huge share of websites, and researchers found a flaw in the PHP engine itself that lets an outside attacker run any code they want. AI played a major role both in finding the flaw and in finishing the exploit, the code that actually attacks it. I didn't run anything myself for this story. Instead I went through the primary sources from Wiz, Amazon and Cloudflare, along with the rebuttals and reactions circulating online.

What did AI do in Wiz's discovery of PHP2Shell?

Start with the primary source. According to Wiz Research's official blog, a team of Sagi Tzadik and three others combined the company's own Wiz Atlas with Gemini 4 Argon and GPT-5.6 Sol to find memory-safety flaws in the PHP engine. A memory-safety flaw happens when a program mismanages memory in a way that lets an attacker overwrite places they should never be able to reach. There are two of them, CVE-2026-109618 and CVE-2026-109619. Their CVSS severity score is 9.2 out of 10, near the top of the scale.

Everything moved fast. The flaws were found on August 19, 2026. Just one to two days later, on August 20–21, the team had confirmed remote code execution, meaning the ability to make a distant server run arbitrary commands, on Drupal and WordPress, two of the most widely used site-building platforms. Every version from PHP 5.4 onward is affected, and about 70% of all websites run on PHP. That gives a sense of how far the flaw reaches.

Wiz writes that Gemini 4 Argon contributed heavily across discovery, exploit development, detection and fix validation. Read on its own, that sounds like "AI did everything." But the same blog post also says plainly that proving exploitability required "a highly complex sequence of steps approaching the practical limits of what a human researcher can manage." I thought that was an honest way to put it. AI isn't a magic wand. It's a tool that makes a skilled researcher many times faster, and that seems closer to what happened here.

Three teams reached the same flaw, and the disclosure plan collapsed two days early

Wiz wasn't the only one to find the flaw. According to Unite.AI, a team called Calif began investigating with GPT-5.6 Sol on August 1. Wiz reportedly arrived at the same two flaws on its own by August 19. In all, three teams, Wiz and Calif among them, found the same flaws independently. If AI lets many different people end up in the same place, that's an unsettling thought.

On October 21, PHP fixed the flaws by releasing four versions at once: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The process was supposed to run quietly through coordinated disclosure, where the finders and the developers agree to go public together once a fix is ready. But according to Unite.AI, the plan collapsed two days before publication. Two reasons have been reported: a demo video leaked, and Chainguard, a company that distributes apps pre-packaged to run immediately (container images), shipped images containing the fix early.

KuCoin News also reported that after OpenAI announced Patch the Planet, three countries, Finland, the Netherlands and France, took government websites offline on October 21. OpenAI's Greg Brockman reportedly said that "the coalition had a two-month preparation window." Reports also say the leaks forced disclosure forward, and PHP moved its release up by one day. Two months sounds like a long time. It was nowhere near enough to patch, on servers around the world, a flaw that had sat in PHP itself for 14 years.

The PHP Foundation has also reportedly acknowledged a "structural failure," saying it knew about related weaknesses but that work on a fix had stalled and restarted for months. The people finding flaws got faster with AI, while the people fixing them are still working by hand. That gap in speed may be the biggest lesson of this whole episode.

Attacks had already begun four days before disclosure

This is where it gets alarming. Amazon Threat Intelligence said its MadPot decoy-server network recorded exploitation attempts targeting PHP2Shell on October 17. MadPot works by deliberately putting out servers that look like easy targets and watching what attackers do. Public disclosure came at 14:00 UTC on October 21, so the attempts started four full days earlier.

On disclosure day itself, the first proof-of-concept code, a sample program that shows an attack is possible, appeared around 02:00 UTC, about 12 hours before disclosure. Between 02:00 and 08:00 UTC, attacks arrived from multiple IP addresses. Amazon writes that AI-powered vulnerability analysis is shortening the time between a patch's release and a working exploit. Compare the code before and after a fix and you can see what was changed. AI dramatically speeds up the job of working backward from there to an attack.

Defenders weren't standing still either. According to Cloudflare's official blog, the company deployed new WAF rules at 03:02 UTC on October 21. A WAF (web application firewall) sits in front of a web app like a gatekeeper and blocks suspicious traffic. The PHP fix came out at 13:30 UTC, which put Cloudflare about nine hours ahead. The release included seven rules for free plans, seven for paid plans and one rule that inspects responses. Requests alone, the orders sent to a server, weren't enough to tell attacks apart from legitimate traffic, so Cloudflare for the first time used an approach that also inspects the server's responses. The company says it had been observing attack attempts before disclosure and kept adjusting its rules as attackers changed their payloads.

One thing doesn't add up, though. ppc.land pointed out that OpenAI's announcement says nothing about the leaks or the pre-disclosure attacks, even though Cloudflare had observed attacks before disclosure and Amazon had logged exploitation four days earlier. That sits awkwardly with the claim of finding the flaw "before attackers did."

Did AI find it, or did AI weaponize it?

The sharpest rebuttal came from Nick Rogers's post on Dead Neurons. His argument is that all the ingredients had been public for years. In 2004, Stefan Esser presented an issue with memory_limit (PHP's cap on how much memory it may use) being interrupted. Bug report #78876 from 2019 described the same out-of-memory condition. A 2024 audit by OSTIF and Quarkslab noticed the same anomaly. Yet nobody had built an exploit. In Rogers's view, what AI shortened was the work of building the exploit, from "months" to "days." It wasn't AI that found the root cause. Counting from the 2004 presentation, this story spans 22 years.

Rogers offers another worrying number. Of the 1.5 million PHP hosts exposed to the internet, 883,717, or 59%, are running versions that are no longer supported. Even with patched versions out, more than half of these servers may never be updated at all.

On Hacker News, much of the reaction was skeptical. SyneRyder wrote that the key to success was having researchers who could drive Sol, which lines up with Wiz's own admission about steps "approaching the limits" of human ability. Others said it was "marketing a bug in 20-year-old code as if it were humanity's first remote execution," and NooneAtAll3 said "AI ruined responsible disclosure." Imperva's analysis also found the attack hard to pull off. Unless the timing and memory layout line up, the worker (the process that handles requests) either crashes or simply responds normally.

A post by someone close to PHP's security team also argued that the information circulating was full of errors. The CVSS score was 9.2, not 10.0. The affected-version list included "PHP 6," a version that was never released. And the widely shared workaround, disabling session.upload_progress.enabled, applies to a different CVE, not the main remote execution flaw. Some people may have changed a setting in a hurry and wrongly concluded they were safe.

What I took away from following this story

To sum up, here's what happened with PHP2Shell. The seeds of the root cause had been around since 2004. In August, researchers using AI built a full exploit in a hurry, and three teams reached the same answer. The window before disclosure was about two months. But information leaked, attacks began four days before disclosure, and government websites in Europe went offline. AI sharply sped up both finding the flaw and building the exploit. Fixing it, distributing the fix and getting systems updated still moved at the speed of people and organizations.

To me, that gap in speed matters more than the argument over whether AI or humans found the flaw. Rogers is right that the root cause had long been known. Wiz is right that the complex steps took human skill. Both are true, and what's new here is that building the weapon went from months to days. If so, defenders can no longer afford to let a fix sit for months. Perhaps that's what the PHP Foundation recognized when it acknowledged a "structural failure."

If you run a site on PHP, start by checking your version and upgrading to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you're on an unsupported version, now is a good time to plan a migration. Before acting on circulating workarounds or figures like CVSS 10.0, check them against primary sources such as PHP's official announcements and the Wiz and Cloudflare blogs. Rushing to respond based only on what's going around on social media is the most dangerous move of all.