AI Is Finding Website Flaws Faster. What That Means for a Small Business Site

As of 23 October 2026, PHP2Shell, a pair of critical flaws in the PHP engine that researchers found with help from AI tools, has been fixed by the PHP project, attackers are widely reported to be trying it, and no public source has documented a confirmed successful break-in. It is the clearest example so far of a trend security agencies have been warning about all year: AI is helping people find software flaws faster, and it is shrinking the time between a patch being published and a working attack appearing.

Here is the direct answer for a small business owner. AI has changed how fast flaws are found and how fast attackers can act on them. It has not changed what protects your website: supported software, updates applied quickly, and a named person or company responsible for applying them. If your site runs on WordPress, Drupal, Joomla or any PHP application, the practical response is a patch-speed plan, not panic.

This guide covers what the evidence says changed, where the evidence is still thin, what stayed the same, and a plan a service business can actually run. For the basics of the flaw itself, start with what PHP2Shell is.

What Changed: Flaws Are Being Found Faster

The credited reporters of PHP2Shell include the security firm Calif, the cloud security company Wiz, and OpenAI's Codex Security team. Wiz says it used "Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol" and that "a single researcher completed in a week what previously would have taken a world-class team months of work." Its 21 October write-up is plain about what was new and what was not: "The vulnerable code had been there for more than a decade – what AI changed was the ability to understand the weaknesses and turn them into a working exploit."

The flaw was not new, and AI did not invent it. The PHP Foundation says the first signs of the out-of-memory problem were found in 2024, during an earlier audit. What changed is the effort needed to go from "this looks odd" to "this works."

The same speed is showing up across the industry:

• Volume of reports. The PHP Foundation says its security team "has published 15 CVEs since July 1st and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible." It adds: "Tools now find bugs faster than ever, for defenders and attackers alike."
• AI labs. Anthropic said in April 2026 that its unreleased Claude Mythos Preview model "has already found thousands of high-severity vulnerabilities, including some in every major operating system and web browser." The PHP Foundation says it used that model, through the Alpha-Omega project, to scan PHP earlier this year.
• Agencies. A June 2026 statement from the Five Eyes cybersecurity agencies, including CISA and the UK's National Cyber Security Centre (NCSC), says AI "lowers barriers for malicious actors and increases the speed and complexity of attacks, shrinking the window between vulnerability discovery and exploitation ever more quickly."

More AI-assisted research means more CVEs (the public ID numbers flaws get when disclosed), and more updates for site owners to apply.

What Changed: The Gap Between Patch and Exploit

For a small business, the more important change is speed after disclosure. When a fix is published, attackers can study what it changed and work backward to an attack. Amazon puts it this way: "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit."

Amazon's 21 October post on PHP2Shell explains why: "In the past, most exploitation we observed came after a public proof of concept was released. A small number of capable actors built exploits, and everyone else waited for them. That dependency is weakening." Its advice is blunt: "For critical vulnerabilities in internet-facing systems, measure patch and mitigation timelines in hours. A 7-day or 30-day SLA assumes a delay that no longer exists."

Several organizations publish time-to-exploit figures, but they measure different things, so they cannot be lined up as one trend line. Each is shown here with its own definition.

The numbers are not comparable, but the direction is consistent: a monthly maintenance visit can now miss the window between "fixed" and "attacked."

Where the Evidence Is Still Thin

Not everyone agrees on how big the AI shift is, and a fair picture includes the skeptics. VulnCheck, which tracks exploitation data, wrote in its July 2026 report: "The data so far, including Anthropic's own stalled disclosure ledger, suggests that AI-assisted vulnerability discovery and frontier capabilities have been overhyped relative to the evidence available today."

It counted 1,061 vulnerabilities attributed to AI-assisted discovery, of which 14, or 1.3%, had been confirmed as exploited, "roughly matching the overall exploitation rate." It also notes that Anthropic reported more than 23,000 findings through its Project Glasswing program, "but only 126 have resulted in published CVEs, and just one has been confirmed as exploited in the wild." VulnCheck does not dismiss the risk: "That doesn't mean the risk is imaginary. It means the impact has been real but modest."

The researchers themselves add caution. Calif, the first to report PHP2Shell, writes: "No model is simply capable of unearthing 'all bugs' with simple prompts," and says that "know your target" still applies. And for PHP2Shell specifically, sources report widespread exploitation attempts but, as of 23 October, no publicly documented confirmed compromise. Our PHP2Shell exploitation tracker keeps the dated details.

Neither side of that argument changes what a site owner should do.

What Did Not Change

Every source on PHP2Shell, from the PHP project to CISA, gives the same core fix: install a patched PHP build and restart PHP. No AI tool, firewall rule or plugin replaces that. The steps are in our fixed versions guide.

The rest of the basics also hold:

• Unsupported software is the easiest target. The Five Eyes statement says: "Unsupported systems are easy targets." PHP 8.1 and older no longer get official releases, and PHP 8.2's security support ends on 31 December 2026.
• Updating by default works. The UK NCSC tells organizations to "put in place a policy to 'update by default' where you always apply software updates as soon as possible, and ideally automatically."
• Less software means less to patch. Patchstack found that 46% of WordPress ecosystem vulnerabilities in 2025 "did not receive a fix from the developer in time for public disclosure." A plugin you removed cannot be one of them.

Why a Small Business Site Is in the Same Line of Fire

Automated scanning doesn't pick targets by size. The security firm watchTowr told SecurityWeek that the PHP2Shell exploits it saw were being "sprayed indiscriminately." A five-page plumbing site on an unpatched server answers a scanner the same way a large one does.

Content management systems are a frequent target in general. VulnCheck reports that content management systems "remained the most targeted technology category, accounting for one-third of all KEVs" in the first half of 2026. KEV is CISA's Known Exploited Vulnerabilities catalog, the government's list of flaws confirmed to be used in real attacks.

Agencies rate the risk to small organizations slightly lower but not low. The MS-ISAC advisory on PHP2Shell rates the risk to "Small business entities" as MEDIUM and to large and medium businesses as HIGH. That is a reason to plan, not a reason to wait.

A Patch-Speed Plan for a Service Business

Most small businesses don't need a security team. They need a short written plan and a person who owns it. Here is one sized for a contractor, clinic, law office or similar service business.

1. Write down who patches what. Your host may patch PHP and the server; you or your developer may own WordPress, plugins and themes. If nobody can answer this, that is the first gap to close. Our guide to the shared responsibility model walks through it.
2. Keep a one-page inventory. List your website platform, PHP version, plugins, any separate tools such as booking forms, webmail or client portals, and who hosts each one. PHP often hides inside other software.
3. Set response targets by risk. Our suggestion, based on the agency guidance above: critical flaws in anything public-facing get patched or mitigated the same day if possible, routine plugin and theme updates weekly, and everything else on a monthly cycle. CISA's federal guidance gives the highest-risk flaws three days, and Amazon argues for hours.
4. Turn on automatic updates where they are safe. For WordPress, that can cover core updates and well-maintained plugins you trust. Our guide to security patching and plugin updates covers how to decide.
5. Have a test copy and a backup ready. Fast patching is much less scary when you can test on a staging copy and roll back if something breaks.
6. Get alerts from first-party sources. Follow your host's status page, CISA's alerts and the vendor of your platform.
7. Remove what you don't use. Every inactive plugin, old test site or forgotten subdomain is something that can fall behind.
8. Plan your way off end-of-life software. If your site runs on PHP 8.2 or older, schedule the upgrade now rather than during the next emergency.
9. Know your emergency path. Decide in advance who you call when a critical flaw lands, and whether you will take the site offline if it cannot be patched quickly. Several agencies advised exactly that for PHP2Shell.

Managed Hosting and Maintenance Are the Real Lever

For a small business, the biggest factor in patch speed is not a tool. It is whether someone whose job is patching is already responsible for your server. PHP2Shell made that visible.

Managed hosts that run PHP for their customers published dated updates. WP Engine reported at 01:19 UTC on 22 October that it "has finished the deployment of security patches" and that "no action is needed from you." Kinsta marked its incident resolved at 08:26 UTC on 22 October, saying "the PHP security updates have been rolled out across the platform." Several other managed and shared hosts published similar statements within a day or two of the 21 October release.

Customers who manage their own servers were in a different position. GoDaddy told VPS customers: "Since you manage your server's software, you'll want to update PHP yourself." Hostinger said "VPS clients manage PHP themselves." Cloud providers said the same about containers that customers build: "Container images you build yourself are your responsibility" (Google Cloud).

If you are on a self-managed server and nobody watches it daily, moving to managed hosting or a maintenance plan is often the single most effective security change you can make. Our guide to managed WordPress hosting explains what to look for. If you are not sure who patches your site today, our copy-and-paste message for your web host gets a clear answer.

Should You Use AI Security Tools Yourself?

The same tools help defenders. The Five Eyes agencies say organizations that "integrate AI tools into their security operations can detect vulnerabilities earlier, improve software quality, monitor unusual behaviour, and respond faster to incidents." VulnCheck goes further and argues that giving defenders frontier models "is more likely to give defenders an advantage in strengthening software than to give attackers an advantage."

For a small business site, that benefit mostly reaches you through your host, your platform's security team and your maintenance provider. Two cautions apply if you experiment:

• Never run exploit code from the internet against your own site. Bitdefender reports that some GitHub repositories claiming to host PHP2Shell exploits are pranks and advises: "Treat every unofficial PoC as untrusted code."
• A clean scan is not proof of safety. For PHP2Shell, PHP's own advisory warns that "absence of an error in logs is not proof of safety," and a version banner can hide a patched build.

Conclusion

AI has made software flaws faster to find and faster to exploit after a fix is published, and PHP2Shell shows both effects. The skeptics have a point that real-world damage from AI-found flaws is still modest in the data, but that debate doesn't change the job: run supported software, patch critical issues the same day, cut what you don't use, and make sure a specific person or provider owns the work. For a small service business, managed hosting or a maintenance plan is usually the fastest way to get there. If you want a review of how your site is patched and protected today, our website security services team can help. For a related look at the platform question, read will AI hacking kill WordPress. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions