Why Attackers Are Betting You’ll Sleep On Patching
AI is shrinking the time from disclosure to exploit. Shane O’Donnell shares six questions to test whether your vulnerability management program can keep up.
The flaws exposed in the recent PHP2Shell cybersecurity crisis weren’t new, but they revealed how AI has changed the speed and economics of cyberattacks. In this blog, we share six questions you should ask to document your digital assets, determine their owners, and get the information you need before the next attack.
Does This Sound Familiar?
It’s 4:50 p.m. on a Saturday. The CFO forwards a news link to the security team with one line: “Are we affected?”
The honest answer is, “Nobody knows yet.”
The team starts pulling threads. The corporate website is easy to check. Then someone remembers the microsite for a product launch that an outside agency built three years ago. It’s still live.
Someone else remembers the HR portal, which a vendor hosts and swears is “fully managed.” Finally, a developer’s test box turns up in a cloud account that nobody in IT knew existed.
By Monday night, the company has patched everything it owns, but getting straight answers from vendors about what runs underneath their products takes until Thursday.
PHP2Shell: From Potential Problem to Crisis
This scenario is hypothetical, but we’ve seen it play out many times with our clients. In late October 2026, companies worldwide lived through their own versions of it.
On Oct. 21, the PHP Foundation released emergency patches for two critical flaws in PHP’s core engine. PHP — a free, open-source web scripting language — runs roughly 70 percent of the world’s websites. The flaws, known as PHP2Shell, could let an attacker run code on a server without logging in.
Researchers found and reported the bugs in August, and the PHP Foundation planned a coordinated release for Oct. 22. But when the vulnerabilities’ Common Vulnerabilities and Exposures (CVE) IDs leaked online Oct. 20, the foundation moved the release up a day.
That set off an international scramble as companies asked the all-important question: “Are we affected?” Technical teams raced to find and patch every vulnerable system.
Then, on Oct. 21, Amazon reported evidence of a failed attack on Oct. 17. Security researchers urged companies to look back to Oct. 17 for signs that attackers had gotten in before a patch existed.
Clear answers were not always easy to find.
That’s the lesson of PHP2Shell. AI has made old flaws, like those in PHP, easier to find and cheaper to exploit. These new factors, combined with today’s expanded threat landscape, make it clear that getting fundamental security questions “mostly right” is not enough.
In this blog, I share more details about PHP2Shell that reveal what has changed for these types of attacks, and I share six questions that require “yes” answers before the next cybersecurity crisis.
Vulnerabilities Aren’t New, But the Economics Are
Serious flaws in widely used software are nothing new. From Heartbleed to Log4Shell to PHP2Shell, the bug class isn’t the story.
The story is the code behind PHP2Shell, which sat in PHP for years, running on servers across the internet the entire time. For traditional hackers, weaponizing the code wasn’t worth the effort and expense, but AI coding agents can do that work in a fraction of the time and cost.
As early as 2024, University of Illinois researchers found that an agent built on GPT-4 could exploit 87 percent of a test set of 15 vulnerabilities once it had obtained their CVE IDs. The agent did so at roughly a third of the cost of a human tester. That study didn’t involve PHP, but the trajectory is hard to miss.
Meet Your New Attacker
For years, a serious exploit required a serious adversary. That filter is largely gone. A bored teenager with a laptop and an AI model can now attempt what used to take a funded team.
You can see the result in PHP2Shell attack traffic. Cloudflare counted millions of exploit attempts within about a day of disclosure. Yet researchers report that most attempts have failed and that much of the public exploit code doesn’t work. Some tools labeled as PHP2Shell exploits don’t target the flaw at all.
In our view, that’s what it looks like when people use AI to build something they don’t understand: broken payloads, wrong targets, and logic that never had a chance of working.
Remember, PHP2Shell’s CVE IDs leaked online the day before the patch, and sloppy exploit code spread across GitHub almost immediately. Attackers built it into their tooling without checking whether it worked. Even the bad guys still need a human in the loop.
None of that should comfort anyone. Failed attempts are still attempts, and volume is the point. A thousand clumsy attackers only need to be right once, and next month’s tooling will be better than this month’s.
Why Every Patch Is a Blueprint
When a vendor ships a fix, it also publishes a map of what was broken. Attackers have compared patched and unpatched code for years to find flaws. AI agents make that process faster and put it within reach of far more people. Once a patch is out, the attacker’s clock runs fast.
PHP2Shell shows the race can start even earlier. After all, the failed Amazon exploit had happened four days before the patch shipped — and while the flaws were still under embargo. After the patch went out, researchers confirmed successful remote code execution in the wild within days.
In other words, you may not get a head start at all. That’s why the safety net we cover below matters as much as patch speed.
Time is no longer neutral. It’s working against you. A 30-day patch cycle was a reasonable business trade-off five years ago. That same cycle gives attackers a wide-open window. Worse, most organizations aren’t hitting 30 days. The Verizon 2026 Data Breach Investigations Report puts the median time to fully patch a known-exploited vulnerability at 43 days.
6 Questions to Ask Before the Next PHP2Shell
Most organizations have gotten by with processes that were incomplete but functional. Inventory was “mostly right.” Ownership was “someone in IT.” Vendor risk was a questionnaire filed once a year.
That worked because exploitation took long enough for teams to catch up. PHP2Shell proves that cushion is gone.
“The industry has been building toward this moment for three decades,” says Mike Hamilton, senior manager of offensive security for Centric Consulting’s penetration testing team. “Basic cybersecurity principles haven’t changed, but they are a much higher priority now. Today’s leaders must ask the right questions to defend themselves.”
The following questions require a “yes” on your end. If the answer to any of them is “no” or “I don’t know,” you’ll know where to start:
- Are we aware of every asset we run, including the ones people would rather forget? A “yes” means you maintain a living inventory that covers cloud accounts, vendor-hosted apps, and the microsites agencies built years ago. In the hypothetical scenario, the patch took hours. Finding the forgotten microsite and the developer’s test box took the rest of the weekend.
- Does all our systems have named, current owners? An owner is a person who can approve a patch or a shutdown outside of normal business hours. People change roles, so check ownership every time you review access.
- Can we patch high-risk systems in days, not weeks, with a pre-approved emergency process? A “yes” means a known-exploited flaw doesn’t wait in line for the next change advisory board meeting. With a 43-day median across the industry, most organizations have room to improve here.
- Do we know which vendors and hosted platforms run the software we’re exposed to? In the opening scenario, the company patched its own systems over the weekend, but vendor answers took until Thursday. A “yes” means your vendors are required, by contract, to disclose their components and alert you within a set time whether they’re affected.
- Do we maintain software bills of materials (SBOMs) and run automated checks against them continuously? An SBOM lists the components inside each application. Paired with automated scanning, it turns “Are we affected?” from a weekend of detective work into a query you can run in minutes.
- Do our leadership, finance, and marketing teams agree about when the business will accept downtime to stop an attack? This question matters more than most leaders realize. The worst time to negotiate whether a campaign page is worth a server compromise is during the incident.
Assume You Will Miss Something, Then Build for It
No organization can patch everything instantly, and new threats keep coming. That’s why an overlapping system of protections still matters. To build such a system:
- Segment legacy systems so one compromise doesn’t become a network compromise.
- Put compensating controls like web application firewalls in front of what you can’t patch yet.
- Run endpoint detection on servers, not just laptops.
- Sound an alert when web servers spawn command shells, a likely indication that an attack is underway.
- Enforce least privilege access so a compromised application account can’t reach sensitive systems, such as payroll.
These layers buy time, which is your most valuable resource when you’re under attack.
Security Has Become a Leadership Decision
In our experience, the organizations that recover fastest from events like PHP2Shell already know where the vulnerable software runs, who owns it, and who can approve downtime. Those answers carry over to whatever comes next.
Most organizations have data sitting on a server that someone is afraid to turn off. Deciding when to turn it off is a business call. That’s why this work needs clear ownership and leaders willing to fund the unglamorous parts of security.
Start with the six questions above and treat every “No” or “We’re not sure” as the next item on your roadmap. PHP2Shell will have been patched and forgotten, but the next attack is already being written — likely with the help of an AI agent.
How Centric Can Help
Our cybersecurity team works with organizations to close these gaps, from automated penetration testing to asset discovery, ownership mapping to SBOM programs, and vendor risk to patch governance. We tie each fix to business risk, build a roadmap leadership can fund, and develop processes that keep working after we’re gone.
If PHP2Shell exposed more questions than answers, let’s talk.
