PHP2Shell hid for 14 years and was found in days. What else is hiding in your stack?

Justin Graham

Principal AI Solutions Architect, Andela

Nov 6, 2026

5 min

PHP2Shell hid for 14 years and was found in days. What else is hiding in your stack?

On October 21, the PHP project pushed out emergency releases for two bugs in the engine itself, now called PHP2Shell. Chained together, they let someone with no login run code on your web server. Attackers were trying within an hour of the news breaking.

If you're on PHP 8.2 or newer, you have a patch, though 8.2 itself reaches end of life on December 31. On 8.1 and older, PHP shipped no new release at all, only minimal source patches for 7.4 through 8.1 that some Linux vendors have since packaged. For anything older, the PHP team's advice is to migrate (BleepingComputer, StackHarbor). I'd guess most large companies have at least one app on old PHP that nobody really wants to own.

What bothers me more than the bug is how it was found. The flaw has been in PHP since 2012. A security firm called Calif found it this summer in a matter of days, using generally available AI models, and a second team found it on its own a few weeks later.

Two bugs, one exploit chain

PHP2Shell is two memory-safety bugs, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS 4.0. An attacker sends a few crafted HTTP requests, and the server ends up running their code before your application has even loaded. At disclosure, Palo Alto Networks counted more than 22.6 million internet-exposed PHP instances that were potentially vulnerable (Unit 42).

The root problem goes back a long way. Calif, the firm that found it first, traces it to a memory-limit bug from 2004. Someone reported a related issue in 2020. A 2024 audit flagged something similar, but nobody could show it was exploitable, so it was never fixed (Calif).

In late July, Calif started looking at PHP as part of OpenAI's Patch the Planet program. By August 1 they had working routes to remote code execution, and they reported the first bug to PHP on August 11. Wiz found the same bugs independently about three weeks later (Wiz). The fix was scheduled for October 21, but reports broke late on October 20, and Cloudflare saw tens of thousands of exploit attempts within 45 minutes (Fortune). Amazon's own honeypots had already logged an exploitation attempt on October 17, four days before disclosure (Amazon, BleepingComputer).

What the AI actually did

You may have seen this summed up as someone asking a chatbot to find something dangerous in PHP. The real story involved a lot more expertise.

Ryan Austin, the Calif researcher behind the find, has followed PHP security for years. He suspected relatives of that 2004 bug were still in the code, and he steered the model toward them. In his write-up he says plainly that simple prompts won't dig up every bug, at least for now (Calif). Once they had the first bug, they had the model turn the pattern into a reusable check, and it led them to a second, unrelated flaw.

Wiz used Gemini 4 Argon, GPT-5.6 Sol, and its own Wiz Atlas tool. They say the models took a lot of the grind out of turning a finding into an exploit that works reliably.

How exposed are you?

The "70% of the internet" headline measures how common PHP is. Your own exposure comes down to who runs it. (Strictly, PHP runs about 70% of websites whose server-side language can be detected, and WordPress alone runs about 42% of all websites, per W3Techs.) If your sites are on managed WordPress or a platform host, the provider runs PHP for you and has probably patched it already. If your own teams run PHP servers, whether that's a WordPress install, a Drupal site, or a custom application, the patching is on you. That's where the real exposure is, and it's usually where the oldest PHP lives.

Because the bug lives in PHP itself, what you've built on top only partly matters. The exact attack path depends on your PHP version and server setup, and the PHP team rates the risk highest on Apache mod_php (BleepingComputer). Even so, Calif got code execution without a login on default installs of WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Laravel, and Symfony (Calif).

If your PHP is current, you're looking at a patch and an unpleasant week. Even then, checking takes more than running php -v. Ubuntu, Red Hat, and others backport the fix without changing the version number, so a patched server can still look vulnerable (StackHarbor). On older versions it's a real project. Getting off PHP 7 means code changes, dependency upgrades, testing, and a rollout plan, and the engineers who'd do that work are probably committed to something else this quarter.

The pressure comes from outside engineering too. The UK's National Cyber Security Centre told organizations to update PHP or take systems offline until they can (BleepingComputer), and your board, auditors, and cyber insurer will all want to know where you stand.

One caveat: nobody has confirmed that attackers are using AI models to exploit PHP2Shell (NeuralTrust). So far, AI models have mattered mainly for how quickly the bug was found.

This won't be the last one

Calif wrote that they didn't expect to find anything serious, since every major AI lab had already pointed its models at PHP (Calif). They found two remote code execution bugs anyway, within days. Two days after the fixes shipped, a third related flaw, CVE-2026-115560, was disclosed (StackHarbor).

Then there's the October 17 attempt. Amazon says it's unclear how the attacker got the details while the bugs were still under embargo. Either the information leaked earlier than anyone reported, or someone else found the bug on their own. The early attempts reported so far appear to have been unsuccessful (BleepingComputer), but either explanation means Calif and Wiz may not have been the only ones looking.

I think that's what to plan around. Finding a deep flaw in a mature runtime used to take months of rare expertise, and that cost kept a lot of old code safe in practice. It costs a lot less now, for researchers and attackers both. Years without an incident used to be reassuring. Now it may just mean nobody has looked hard with AI models yet, and that goes for whatever else is old in your stack.

Defenders get the same tools, though. The method Calif used, an expert pointing a model at the patterns most likely to hide bugs, can be aimed at your own code too. And AI agents are genuinely good at the slog of upgrades: refactoring for a new language version, writing tests around legacy behavior, moving a system to a new platform. It doesn't replace the experienced engineer who decides where to look and signs off on what ships. Calif's result came from an expert driving the model, and defense needs the same.

If I were in your seat this week

Find every PHP install. That means marketing sites, internal tools, the WordPress site an agency built a few years ago, and anything behind the VPN. Searchlight Cyber has released an open-source scanner that tests whether a host is exposed (Help Net Security).
Patch what you can. The fixed upstream releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35 (BleepingComputer). If you use distribution packages, check the changelog for the CVE numbers, since the version string may not change.
For anything you can't patch yet, Calif has published temporary mitigations for PHP-FPM and mod_php (Calif). PHP's own developers have said no mitigation fully blocks the attack (BleepingComputer), so treat them as stopgaps only.
Treat anything exposed and unpatched since at least October 17 as possibly compromised. That's the date of the earliest exploitation attempt Amazon has reported, and Amazon advises investigating from that date (BleepingComputer). Check the logs and look for web shells.
Start scoping the upgrade or migration for everything on 8.1 or below, and put 8.2 on the list too, since it reaches end of life on December 31.

Getting step 5 done

Step 5 is the one that tends to sit on a list. Patching a current server takes an afternoon. Getting a ten-year-old application onto a supported runtime without breaking it is a project, and the engineers who could do it are already spoken for.

This is the work we do at Andela. You could hand your team Claude Code or Copilot and ask them to do it, and if they have the time and the PHP history, that may work. Most teams don't have the time. We bring the people and the judgment, working on the tools you've probably already bought. We decide what gets built, check what the AI agents produce, and own what ships into code we didn't write.

Tests come first. In one engagement, a client had three months to rewrite its entire product, a PHP application built on the Laravel framework, while every deploy was introducing new bugs. Our engineers started by writing tests against the existing platform, then rebuilt from there. The client hit the deadline, and a critical workflow went from 39 seconds to one second.

An engagement starts with a two-week assessment. You get an inventory of every PHP install and version, including the ones hidden behind backported version numbers, with internet-facing systems flagged. We sort each system by one question: Can it be upgraded inside a sprint? If so, it's brownfield and gets an upgrade plan. If not, it's legacy, and you get an honest read on whether to upgrade or migrate off. Every system comes with an effort and risk estimate, and the plan is yours to keep.

Before you commit any build budget, we walk you through what we found against what everyone assumed, so changes to scope and cost happen up front, not halfway through. Then we own delivery in your codebase: written specs before any code is generated, human review scaled to risk, and test coverage around legacy behavior before anything moves. If your security posture rules out outside model providers, we plan for that up front. Your team signs off at each gate, and works alongside us if it has the capacity.

Before handoff, we run an AI-assisted security review of your application code, focused on the vulnerability classes most common in legacy PHP. Modernizing should make the next runtime flaw like PHP2Shell is a routine patch; the review covers the other half of the risk, your own code. You also get the documentation, tests, and reasoning behind every change, so whoever maintains these systems next starts from a clear record.

If step 1 turned up more PHP than you expected, or you're not sure it found everything, book a discovery call and we'll start with the inventory.