PHP2Shell: The Race to Patch Now Starts at the Announcement
PHP gave a day's notice of fixes for two critical flaws. Attackers used that day, with help from AI agents, and exploitation attempts were already being detected when the patch shipped. What that means for how you plan for the next critical fix.
On 20 October 2026 the PHP project gave a day’s notice that fixes for two critical vulnerabilities, since named PHP2Shell, were on their way. Responsible disclosure, done the way it has always been done.
The warning was meant to give defenders a head start. Instead it started a race, and by the time PHP shipped its patches, security firms were already seeing exploitation attempts.
What happened
The first warning was not PHP’s own. At around 15:00 UTC on 20 October, the two CVE IDs began circulating on forums and social media, with the wrong release time and the wrong severity score attached. No technical details leaked. PHP responded by publishing its pre-announcement at 19:30 UTC and moving the release forward a day, to 14:00 UTC on 21 October.
So for a day, the public knew little more than that two critical flaws existed in PHP. That was enough to start work. Individuals and organisations pointed AI agents at PHP’s source code, attempting to rebuild the exploit chain. A video of a working proof of concept was posted then deleted later that evening, but not before it gave away a few more details. Proofs of concept began circulating shortly after.
By the time PHP shipped its patches, security firms were already seeing exploitation attempts. Cloudflare reported attack traffic targeting its customers, with attackers changing their payloads to try to get past its firewall rules. PHP’s security team, which inspected the proofs of concept as they appeared, stated they had not found a working one by the time the patch released.
The PHP Foundation’s account of the release sets out the full timeline. If your sites run PHP, our guide to the 21 October release covers which versions are fixed and how to check where your site stands.
The race used to start at the patch
For years, the dangerous moment in a vulnerability’s life was the release of its fix. A patch shows exactly what changed, allowing attackers to work out what was broken and build an exploit for everyone who has not updated yet. The practice is common enough to have a name: patch diffing.
It took skill and time. Turning a fix into a working exploit could take days or weeks, and that gap was the defenders’ time to act. Organisations could book the maintenance and researchers could notify anybody who was yet to update.
The patch shows attackers what to exploit
The race begins when the fix is published. Attackers reverse-engineer the change while defenders roll out the update.
The announcement is enough
The race begins with the warning. Attackers can be working on an exploit before the fix exists, while defenders can only prepare.
Now it starts at the announcement
An announcement like PHP’s gives little away, but it narrows the search. It names the software, says the flaws are critical and, with a fix due the next day, tells you the bug is specific and already understood. When the source code is public, that is enough of a starting point.
Searching a codebase the size of PHP for a flaw you know is there used to take an experienced researcher and a great deal of their time. An AI agent can now do much of that work for anyone who asks, and keep at it around the clock. PHP2Shell itself shows how far that has come: researchers at Calif, OpenAI and Wiz found the flaws working with AI models, and Wiz put the change plainly:
“A single researcher completed in a week what previously would have taken a world-class team months of work.”
Wiz Research
It took no special access. Calif, one of the first to report the flaws, says no special harness or models “that weren’t generally available to everyone” were used in the initial discovery. OpenAI, whose models helped find them, is just as direct: “the same capabilities can also help attackers rapidly develop offensive tools.”
OpenAI called the months between discovery and disclosure a “Defender’s Window”: time for maintainers and security providers to prepare fixes and protections before attackers find the flaw. That window used to survive an announcement, because knowing a flaw exists is a long way from knowing where it is. With AI agents doing the searching, it no longer does. For PHP2Shell, attackers caught up within a day of the CVE IDs becoming public: exploitation attempts began before the patch was out.
Safeguards only cover the models that have them
AI providers did try to slow this down. Anthropic and OpenAI blocked requests that went looking for PHP vulnerabilities while the fix was pending, and that will have stopped some attempts. It is a hard line to hold: OpenAI acknowledges that safeguards intended to prevent abuse “can also block legitimate security work”.
It cannot stop all of them. Capable models can be downloaded and run on private hardware, where no provider sees the request and no safeguard applies. Provider safeguards raise the bar for casual attempts. They do nothing about a determined attacker running a model of their own.
That is the reality to plan for: the next critical announcement will be read by people with capable AI agents and no limits on what they can ask of them.
Planning for the next one
Responsible disclosure still matters, and a day’s notice is still worth having. What has changed is what the notice is for. It is no longer time to get ahead. It is the start of the race.
Act on the announcement, not the release
When a vendor warns that a critical fix is coming, start that day: confirm what is affected, book the change window and have people ready, so the update goes on within hours of release rather than days.
Know where your software runs before you need to
An up-to-date list of servers, versions and owners turns “are we affected?” from a day’s work into a lookup. Our guide to the PHP release shows how to check a site’s version.
Have mitigations that do not wait for the patch
Firewall rules, restricting access to affected services or switching off a vulnerable feature can cut your exposure while a fix is pending. Cloudflare had rules protecting its free and paid customers from 03:02 UTC on 21 October, almost 11 hours before PHP’s patches shipped. Ask your hosting provider or firewall vendor what they can put in place.
Assume someone tried before you patched
When attacks start before the fix, patching closes the hole but does not tell you whether anything got in. Check for unfamiliar files, new administrator accounts and scripts you did not add.
Watch for change, not just versions
A version number tells you whether you were exposed. Watching the pages and scripts your sites serve tells you whether something changed, at the moment it happens.
The race now starts at the announcement, not the patch.
Patch fast, and watch faster. Website Monitoring keeps watching your pages and the code they load, so a change you did not make is flagged when it appears, not when a customer reports it. Website Malware checks your sites from the outside for hidden code, card-stealing scripts and vandalised pages, with evidence your team can act on.
