The PHP2Shell episode is being told as a story about AI finding catastrophic bugs. The more consequential fact is that the coordinated-disclosure process failed. Amazon's honeypots logged an exploitation attempt on October 17, four days before the embargo lifted. Working proof-of-concept code circulated by the evening of October 20 Pacific Time, still before any patch existed. For roughly ten hours, the only protection most PHP sites had came from firewall rules pushed at the network edge, not from the software itself. In that window, the economics of web security shifted toward whoever controls the traffic in front of the server.
The Embargo Failed Before the Code Did
The two flaws, CVE-2026-109618 and CVE-2026-109619, are remote code execution bugs in the PHP engine. They had sat in the codebase for years. According to Wolf Richter's account on WOLF STREET, researchers found them in August using OpenAI's GPT-5.6 Sol model. They then spent about two months coordinating with the PHP project, OpenAI, and WordPress on a fix. The patch was scheduled for October 22. The embargo was set to lift at 14:00 UTC on October 21.
That schedule assumed the people who knew about the bugs were the only people who knew. It was wrong by at least four days. AWS said its MadPot sensors caught an attempt on October 17 from an IP tied to a commercial anonymization network. AWS also said it "remains unclear how the actor acquired exploit information prior to disclosure."
That unanswered question carries a lot of weight. A leak from inside the disclosure circle is one explanation. Independent rediscovery is the other. If one frontier model can surface a decade-old RCE in a language this widely deployed, other capable models can too, and some of their operators will not call the vendor. Nothing in the public record establishes which happened here, and the article does not claim to know. Either explanation leads to the same conclusion, though. A two-month embargo is a long time to keep a secret that machines can find on their own.
Ten Hours Without a Patch
Cloudflare CEO Matthew Prince described the exploitation curve on X. Thousands of attempts arrived in the ten hours before public announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions by that night. AWS confirmed the same pattern. New proof-of-concept exploits appeared within hours of the patch release and hit its sensors "almost immediately."
The fix itself was large. The Wall Street Journal reported it touched nearly 200 files and required more than 10,000 lines of code. A change that size cannot be rushed out safely in an afternoon. That explains why the emergency release came only when the leak forced it, and why hosts then needed hours to build and deploy it across their fleets. WOLF STREET's host, Liquid Web, had the site patched by the afternoon of October 21.
The time between when exploitation started and when patching finished is the period that matters for risk, and for many operators it lasted days rather than hours. Patching is the cure. It was simply unavailable during the stretch when attacks were ramping up.
Who Actually Absorbed the Risk
Three groups paid three different prices.
The first group shut down, which was the recommended response with no patch available. Richter reports that government, hospital, and essential-service sites across Europe went dark. The St. Louis Fed took FRED offline, a heavily used data site that any attacker would see as a prominent target. These operators turned a security risk into lost availability, which is the cost of having no defense in front of the server.
The second group stayed up behind an edge firewall. Cloudflare said it built PHP2Shell mitigations "in the hours before the public announcements," which means it had working rules while the embargo still held. Richter kept WOLF STREET online on the strength of Cloudflare's firewall and the Wordfence plugin. He called this "hope," which is honest. Still, the hope rested on a specific mechanism: a filter that inspects the crafted queries the exploit needs before they reach PHP.
The third group was the maintainers. A volunteer-heavy open-source project had to ship a 10,000-line emergency change on a schedule set by an anonymous attacker. That cost appears in no company's financial statements. It is still a real and growing liability, because the discovery rate for bugs like this is now set by AI tools while the rate of repair is still set by humans.
The equity-relevant point concerns who sells the second outcome. Cloudflare, AWS, and managed hosts like Liquid Web are not just vendors that suffered through the incident. They are the only parties whose product worked before a patch existed. Prince's exploitation timeline reads as incident telemetry, and it also reads as a demonstration of the product. Companies do not report figures like these in formal guidance, but they shape how buyers make decisions afterward.
The Case That This Was a Near Miss, Not a Shift
The strongest counterargument is that nothing broke on a large scale. The patch shipped the same day the leak forced it. Large hosts deployed it within hours. A small independent publisher ran through the whole episode without going offline. Log4Shell in December 2021 followed a similar arc, with mass exploitation within hours of disclosure, and the web absorbed it. On that view, PHP2Shell is ordinary vulnerability management under stress, and a sustained shift in spending is not justified.
That counterargument gets the outcome right and the mechanism wrong. Log4Shell was found by human researchers at human speed. PHP2Shell was found by a model, in a language that the source says runs about 70% of websites, after the bugs went unnoticed for years. If AI tools are now finding long-dormant flaws in core infrastructure, both the frequency of these events and the share of them that leak or get rediscovered before patching should rise. One clean recovery does not show that the system can handle a higher rate of incidents.
There is a second weakness in the bullish read. Whether demand for edge security becomes measurable revenue has not been verified. Most of the sites that shut down were public-sector and nonprofit operators with procurement cycles that span years, not quarters. The link from "the WAF worked" to "WAF bookings accelerate" is a hypothesis. It is plausible, but no available evidence confirms it.
The Disclosure That Will Tell
The decision variable is whether AI-driven bug discovery keeps getting ahead of embargo timelines. Three observable conditions would confirm the read. First, a second AI-discovered RCE in widely deployed open-source infrastructure, exploited before its embargo lifted. Second, disclosure frameworks shortening their standard windows, or vendors moving to edge-first mitigation as the default first response. Third, edge-security vendors starting to describe pre-patch mitigation as a distinct line in their commercial disclosures rather than as anecdotes in executive posts.
The read is wrong if PHP2Shell turns out to be a single leak from inside the coordination group and the next AI-found flaws stay under embargo until patched. In that case the episode was an operational-security failure, and the edge layer earned a good news cycle rather than a lasting change in budgets. Until that question is settled, the most consistent reading of the evidence is this: the ten hours without a patch were the real event, and the companies that could filter traffic during those hours were the only ones selling protection at the moment it was needed.
