What php2shell Taught Us About Patch Speed
A leak, a fix and attacks, all in one day
On October 20, details of two critical flaws in PHP leaked online. PHP is the language behind about 70% of the web, including WordPress, WooCommerce and Magento. The flaws, now called php2shell, let attackers run their own code on a web server without logging in.
The PHP team rushed the fix out the next morning. Attack attempts were reported the same day.
The technical details matter to the people running PHP servers. The lessons apply to every business with a website, a store or an internal tool, whatever it runs on. Here is what we took from it.
Lesson 1: The window is now hours, and AI is why
Two years ago, a business had weeks between a flaw going public and attackers using it. That buffer is gone.
People hunting for flaws now work with AI. Google's threat intelligence team counted 5,045 new vulnerabilities disclosed in January 2026 and 10,740 in August. More than double in eight months. And the flaws found with AI help skew serious: half of them let an attacker run code on the server. For the rest, it is about a quarter.
Attackers use AI to turn a fix into an attack. Every security update shows exactly what was broken. An attacker can hand that change to an AI model and get working attack code far faster than writing it by hand. Google says attackers are likely doing this already. In one case, six separate groups were exploiting a flaw within a week of it going public.
AI lowers the bar. Writing a working attack used to take rare skills and days of effort. With AI doing much of the work, far more people can do it, and in hours. More attackers, each working faster, means more scans hitting your systems sooner after every fix.
You are not a target. You are in range. Most of these attacks are not aimed at anyone in particular. Attackers scan the whole internet for anything still running the vulnerable version and hit every match automatically. A small business site is as easy to find as a bank's, and often easier to break into. Being unpatched is the only qualification.
php2shell followed the pattern. Code claiming to exploit it was circulating as soon as the details leaked. Our own work runs on these same models, and we see how fast they read and write code. Assume anyone who wants into your systems has that speed too.
Lesson 2: Patch speed is decided before patch day
Teams that patch a critical flaw in hours are not faster on the day. They set things up so a patch is just a normal update.
On a well-run setup, every rebuild pulls in the latest security fixes automatically. The new version starts next to the old one, gets checked, and only then takes over the traffic. Visitors notice nothing. It can happen at 2 p.m. on a Tuesday.
On a typical setup, the fix needs a code change, a test, a maintenance window and someone who remembers to do it. That takes days. When attacks start within hours, days is too long.
Lesson 3: The forgotten sites get you
Your main website gets attention. The risk lives elsewhere.
The staging copy, the old campaign page, the admin tool an agency built in 2022. They were set up by hand, nobody updates them, and attackers find them with the same automated scans that find your main site. If something only gets updated when someone touches its code, a quiet tool can run years out of date.
The fix is boring: every app builds the same way, and every app rebuilds on a schedule, even when nobody changed it.
Lesson 4: A firewall buys time. It is not the fix.
Providers like Cloudflare shipped emergency firewall rules for php2shell within hours. That helps. But firewall rules can be bypassed, and traffic inside your own network never passes through them. Only the update closes the hole.
And updating does not tell you whether someone got in first. For anything that was exposed before its update, someone should check for files that were added or changed, look for unusual activity in the logs and review what the firewall blocked. If a system holds passwords or API keys, changing them is the cautious move.
Questions to ask whoever runs your systems
You do not need the technical details. You need answers to these.
- Do we have a list of every site and tool we run, with what it runs on? Including the ones nobody has touched in a year.
- How long would it take to apply an urgent security fix to all of them? Hours is the answer you want.
- Can you update without taking anything down? If the answer involves a maintenance window, ask why.
- Which of our systems can anyone on the internet reach? Admin panels and staging sites should require a login before anyone even sees them.
- If someone got in before the fix, would we know? That means logs kept somewhere they survive an update.
A good developer or agency answers all five in under an hour. If it takes a week of investigation, the problem is bigger than this one flaw.
How we approach this
We build custom AI agents and the apps around them. Those apps handle customer data, connect to CRMs and inboxes, and run every day. A security update has to be routine for them, not an emergency project.
So every app we ship follows the lessons above. Every rebuild picks up the latest security fixes. Apps rebuild on a schedule even when nobody touched the code, so quiet tools stay current too. Updates switch over with no downtime. And we can list every running app with its exact version in one step, so "are we affected?" takes minutes to answer.
None of this is exotic. It is setup work most teams skip because nothing has gone wrong yet. We wrote about the same pattern with AI-generated code: speed without the safety work catches up with you eventually.
php2shell will not be the last critical flaw this year. With AI on both sides, the next one will come with an even shorter window. What decides your exposure is the setup you have in place before it arrives.
