PHP 7 end-of-life security vulnerability AI exploits 2026
|

The PHP 7 Time Bomb: 38% of the Web Runs End-of-Life PHP — And AI Is About to Set It Off

Table of Contents

Table of Contents

Somewhere in Drupal’s patch notes and security advisories, there’s a line that appears every few weeks: “Exploits could develop within hours of disclosure.” That warning exists because of a structural problem at the heart of modern web infrastructure — millions of websites still run on PHP 7, a version that reached end-of-life in November 2022. And in 2026, that problem is getting dramatically worse, because AI-assisted exploit development means the gap between vulnerability disclosure and working exploit is now measured in hours, not days.

This is the hidden crisis nobody is talking about: a “PHP 7 time bomb” sitting under an enormous slice of the internet. WordPress, Drupal, Joomla, Magento, Laravel applications — hundreds of millions of websites and web applications that have never been upgraded past a version that no longer receives security patches. As AI dramatically accelerates exploit development, these unpatched legacy stacks are becoming catastrophic liabilities.

The Scale of the Problem

According to W3Techs tracking data from early 2026, approximately 38% of all PHP websites still run PHP 7.x. Given that PHP powers roughly 77% of all websites with known server-side languages, that represents hundreds of millions of live, publicly accessible web properties running end-of-life software.

PHP 7.4 — the last PHP 7 release — reached end-of-life in November 2022. That means these sites have received no security patches for over three years. Every CVE discovered in PHP since late 2022, every new class of memory corruption or type confusion vulnerability, goes unpatched on PHP 7 installations. The vulnerability count is not small: the PHP security team has patched dozens of issues in PHP 8.x that would affect PHP 7.x if they were still maintaining it.

Why PHP 7 Sites Haven’t Upgraded

PHP 8.0 introduced breaking changes. PHP 8.1, 8.2, and 8.3 went further. Upgrading from PHP 7 to PHP 8 isn’t a click-and-done operation — it often requires:

  • Auditing and updating third-party plugins and dependencies
  • Rewriting code that uses deprecated functions or removed functionality
  • Testing extensively in staging environments
  • Coordinating with hosting providers for server-level upgrades
  • Budget and developer time that many small organizations don’t have

For a large enterprise with a dedicated development team, this is a manageable if painful migration. For the millions of small businesses, nonprofits, government agencies, and individuals running PHP-powered sites on shared hosting, it’s often simply not done. The site works. Upgrading might break it. So it doesn’t get upgraded.

This is rational behavior at the individual level and a collective catastrophe at scale.

AI Makes This Far More Dangerous in 2026

Here’s what changed: the barrier to exploit development just collapsed. AI-generated zero-day exploits are now a confirmed reality. For legacy PHP 7 sites, this means:

  • Known PHP 7 CVEs that were previously theoretical threats now have AI-assisted working exploits
  • Vulnerability researchers (and criminal actors) can now audit PHP 7 codebases at scale using AI, finding novel flaws in hours instead of weeks
  • Automated scanning combined with AI-generated exploit code means PHP 7 sites can be compromised at industrial scale by relatively unsophisticated attackers

The Mandiant M-Trends 2026 report documented that AI is fundamentally changing the economics of cyberattacks: tasks that previously required skilled specialists can now be delegated to AI agents. Legacy PHP sites — with their predictable vulnerability patterns and massive install base — are ideal targets for this new class of AI-assisted attacks.

The WordPress Specific Risk

WordPress powers approximately 43% of all websites. Its minimum PHP requirement is PHP 7.4 — meaning WordPress will technically install and run on a version that’s been EOL for over three years. WordPress’s own recommendation is PHP 8.1 or higher, but the platform does nothing to force upgrades, and millions of site owners don’t notice or act on the “update PHP” warning in their admin dashboards.

More critically: WordPress plugins inherit their security posture from the underlying PHP version. A plugin with a code injection vulnerability that would be mitigated by PHP 8’s stricter type handling becomes a full exploit path on PHP 7. The attack surface is compounded by the plugin ecosystem’s fragmentation.

What Organizations Should Do Right Now

If you manage web infrastructure and haven’t already, here’s the priority order:

  • Audit your PHP versions immediately: Run php -v on your servers, or check your hosting control panel. Any PHP 7.x version is end-of-life and must be treated as a security liability
  • Upgrade to PHP 8.2 or 8.3: PHP 8.1 is now approaching end-of-life in December 2025; target 8.2 or 8.3 for maximum patch coverage
  • Test in staging first: Don’t upgrade production directly — use a staging environment to catch compatibility issues with your specific CMS, plugins, and custom code
  • Enable automatic security updates: For WordPress, enabling automatic core security updates provides some protection even on legacy PHP
  • Consider managed hosting: Managed WordPress and Drupal hosting providers typically handle PHP upgrades proactively — worth the cost premium for organizations without dedicated DevOps

The Hosting Industry’s Responsibility

Shared hosting providers share responsibility for this crisis. Many still offer PHP 7.x as an option — and some have it as the default for legacy accounts. The business rationale is understandable: forcing PHP upgrades breaks customer sites, generating support tickets and churn. But the security argument for forcing upgrades (or at minimum making PHP 8 the default for new accounts) is overwhelming.

A few major hosts — SiteGround, WP Engine, Kinsta — have been aggressive about sunsetting PHP 7 support. Others continue to enable it quietly for customers who never ask. In 2026, with AI tools making vulnerability exploitation dramatically cheaper, that passive enablement is becoming actively harmful.

The PHP 7 time bomb has been ticking since November 2022. In 2026, with AI-assisted exploitation now confirmed as a real threat vector, the fuse is shorter than it’s ever been. The question isn’t whether legacy PHP 7 sites will be massively compromised — it’s when. And the answer is: probably sooner than most site owners expect.

Sources: PHP.net — Supported Versions | W3Techs — PHP version statistics | Drupal.org — Security advisories

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *