Amazon runs sensors across the internet designed to be attacked, so that its threat intelligence team can watch what attackers try. On 17 October 2026 those sensors recorded an attempt to exploit a flaw in PHP. The PHP project published the fix, and the rest of the world learned the flaw existed, on 21 October.
Somebody was using it four days before it was announced. That ordering is the story — not the bug.
The window used to run the other way
For most of the past decade the rhythm of a serious vulnerability was familiar enough to plan around. A fix shipped. Security teams read the advisory and scheduled the work. Somewhere between several days and several weeks later, working exploit code appeared and the opportunistic scanning began. The gap was uncomfortable, but it was a gap, and patching inside it was a realistic goal for a competent team.
With the PHP flaws disclosed last week — the pair nicknamed PHP2Shell — the gap had already closed before the starting gun fired. Cloudflare had protective rules live roughly nine hours before the public announcement. Its chief executive described attempts numbering in the thousands before disclosure, rising to millions afterwards. There was never a quiet period in which to plan.
AI is part of why
It would be convenient to treat this as one unusual bug. The researchers who found it do not.
Wiz, who co-reported one of the two flaws, observed that the underlying weaknesses had been sitting in PHP for years, and that what made them hard to exploit was the complexity of the chain required — a barrier they credit current AI models with substantially lowering. Amazon made the same structural point from the defensive side: the interval between a patch shipping and a working exploit existing is compressing, partly because AI-assisted analysis makes the job of turning one into the other cheaper than it used to be.
That cuts both ways, and it is worth reading carefully. The same capability that lets a defender read a code change and understand its significance lets an attacker do it faster than before. The asymmetry has not reversed. It has simply accelerated, and the side with less process is the side that feels the acceleration first.
The arithmetic most organisations are quietly failing
Qualys measured patch uptake in the first twelve hours after the PHP release and counted roughly 199,000 instances updated. Against its own telemetry of around 156 million installations, that is a rounding error.
The deeper number is worse. Qualys put roughly 110 million of those installations — about 71% — on branches already past end of life, meaning no patch exists for them at any speed. Independent scans by other firms place the end-of-life share somewhere between 71% and 79%. Whatever the precise figure, the majority of PHP reachable from the internet cannot be fixed by patching at all.