PHP2Shell and the AI exploit: what changed for anyone shipping code

Last updated: November 2, 2026

TL;DR

PHP2Shell shows the patch window is now measured in hours, and AI is part of why. Researchers used frontier models to turn a PHP bug class written off as unexploitable in 2024 into working remote code execution. Attackers were probing within hours of the fix. If agents ship your code, runtime patching has to run as a pipeline, not wait for your next feature push.

• 🐘 What broke. Two critical bugs in the PHP engine itself (CVE-2026-109618 and CVE-2026-109619), CVSS 9.2, no login needed, in every PHP version back to 5.4. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• 🤖 Where AI came in. Wiz says frontier models did much of the exploit work. Calif steered an LLM with prior knowledge of PHP's memory bugs. The attacker who rooted 25 firewalls had Claude Code on their servers.
• ⏱️ How fast it moved. Probing started four days before disclosure, scanners were sending exploit requests about five hours before PHP's own release went out, and the first government system was rooted about 53 hours after it.
• 🔧 What to change. Know which runtimes your images ship, rebuild when upstream patches, let an agent open the patch PR behind your tests, and watch what your web workers spawn.

What PHP2Shell is

PHP2Shell is a pair of memory-safety bugs in PHP's core engine that let an unauthenticated attacker run code on the server. Both CVEs score 9.2 on CVSS v4.0. Because the flaw sits below the application, a perfectly written WordPress, Drupal or Laravel app on a vulnerable PHP build is still exposed. Updating PHP is the only complete fix.

The mechanism is unusual. An attacker sends a request built to make PHP run out of memory partway through setting the request up. PHP's cleanup then trusts half-built data (CVE-2026-109618), or a later request on the same worker reuses state whose memory was already freed (CVE-2026-109619). Huntress describes both. Wiz also showed a Heartbleed-style read of worker memory that can expose passwords, tokens and API keys from other people's requests.

Source: the PHP security advisory of October 21, 2026. It is blunt: "There are no complete mitigations, updating is the only safe choice." Every SAPI that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. watchTowr ranks mod_php highest, because the attack can land before any application code runs.

The exposed base is mostly old. Modat counted 4,384,302 internet-facing PHP services that report a version, and about 79% run a branch PHP no longer supports. PHP 7.4 alone accounts for 878,761 of them (Notebookcheck). None of those gets an official release for this.

How AI turned an old PHP bug into an exploit

AI did not find PHP2Shell from a blank prompt. It made a known bug class cheap enough to exploit. Calif's researchers had spotted these out-of-memory issues in 2024 and judged them unexploitable, so they stayed unpatched (TechCrunch). In 2026, with models doing the slow middle of the work, the same class became remote code execution.

Wiz, on the defense side. Wiz found the first bug on August 19 and reported it to PHP on August 24. Its write-up credits Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas across discovery, exploit development, detection and patch validation. The models adapted exploits to different PHP versions, configurations and memory layouts, reading failures and iterating with debuggers. Wiz's summary: "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." One script got unauthenticated code execution on the stock wordpress:latest, drupal:latest and joomla:latest containers (Wiz).

Calif, on the method. Calif steered an LLM through PHP's allocation, fatal-error and shutdown code using what its researchers already knew about the engine's memory-limit bugs. That lineage runs back to a 2004 memory_limit flaw. Calif was careful about the limits: "No model is simply capable of unearthing 'all bugs' with simple prompts" (TechCrunch). Expert direction did most of the work. The model made it faster.

The attacker, on the offense side. Israeli firm Dream traced a suspected China-nexus actor who chained PHP2Shell with a Linux kernel privilege escalation (CVE-2026-46300) and rooted 25 firewall management servers in the US, Japan, Taiwan and South Korea. Three were in a US government-affiliated network. The targets ran PHP 8.0.30, a branch with no official fix. Dream found Claude Code installed on the attack infrastructure, an AI offensive platform configured with DeepSeek and Kimi models, and nearly 40 scripts with the structure and comments of AI-assisted code (The Hacker News).

The same class of tool sat on both sides of one bug in one month. The tools you ship with are the tools the other side ships with.

How fast PHP2Shell went from patch to attack

From fix to working attack took hours, not weeks. By the timestamps in the public reports, the first exploit request landed before most defenders could download the patch, and the first government system fell about two days after release. Five days after the fix, CISA listed the bugs as actively exploited.

The Chainguard time is inferred from ELLIO's report of a first request under an hour after the images went out. Two gaps in that table matter. ELLIO's first request came about five hours before PHP's own release, because a fixed binary is a map to the bug. The PHP Foundation said the early images let attackers study the fix in binary form while everyone else waited, which "disregarded weeks of work by many parties toward a coordinated disclosure." Then about 53 hours passed between the release and the first rooted government system.

Defenders did move fast where they could. Wiz measured a roughly 67% drop in exposed vulnerable machines within a few days, and one week after disclosure fewer than 53% of initially affected organizations were still vulnerable (Wiz). Read the other way, nearly half were still exposed a week in, after KEV listing, while attacks were confirmed. Managed hosts like Kinsta had Cloudflare WAF rules blocking attempts while it waited for PHP's patch, and marked the incident resolved the next morning. That is the difference between a pipeline and a to-do item.

What builders shipping with agents should change

Treat runtime patching as a pipeline that starts when upstream ships, not when someone notices. Four pieces cover it: know what runtimes you ship, rebuild on upstream releases, have an agent open the patch PR behind your tests, and watch what your web workers spawn. Each one would have mattered here.

1. Know which runtimes your images ship. PHP shows up in more places than PHP apps. Huntress lists vendor appliances, control panels such as cPanel and Plesk, and Windows software that bundles php-cgi.exe. The rooted firewalls were not anyone's web app. Generate a software bill of materials for each image with a tool like Syft or Docker Scout, so "do we run PHP 8.0 anywhere?" has an answer in seconds.
2. Rebuild when upstream patches. Pin base images by digest and let Renovate or Dependabot open the bump. A pinned digest that nobody bumps is a frozen vulnerability. After the update, restart every worker. watchTowr calls this out because a long-running worker keeps the old code in memory.
3. Let an agent open the patch PR, and let your tests decide. The slow part of a runtime bump is the check that nothing broke, not the edit. An agent can read the advisory, bump the version, run the suite and open the PR the same hour. The gate is the review and the CI you already trust, the same setup we describe in compound engineering with an AGENTS.md. If you review agent PRs with a tool, our comparison of /code-review and /ce-code-review covers where each one catches more.
4. Watch what your web workers spawn. PHP2Shell runs below your application, so app logs show little. Huntress's detection advice is to alert when php-fpm, httpd or apache2 launches a shell, an interpreter or curl/wget. Wiz adds memory-limit errors after unusual multipart requests and unexplained worker churn. A web worker should almost never start sh.

Two things did not hold up as fixes. Config workarounds were partial at best: PHP's own advisory says settings like session.upload_progress.enabled=0 "reduce exposure to specific attack paths but do not make an installation safe." And waiting for a CVE to reach a vendor dashboard cost days that the timeline above did not have.

If you run anything on PHP 8.1 or older, the plan is an upgrade, not a patch. CISA advised taking PHP systems offline if they cannot be updated or still run PHP 8.1 or earlier.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. Both let an attacker run code on a PHP server without logging in, by forcing out-of-memory errors during request setup. Every PHP version back to 5.4 is affected by at least one of them.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, 2026. PHP 7.4, 8.0 and 8.1 get no official release, only minimal source backports on php-src branches, so check your distribution or LTS vendor. PHP 7.3 and older have no fix. Restart every PHP worker after updating.

Did AI find PHP2Shell?

AI helped, with expert direction. Wiz credits Gemini 4 Argon, GPT-5.6 Sol and its Wiz Atlas tool across discovery and exploit development, and Calif steered an LLM using prior knowledge of PHP's memory bugs. Calif noted that no model finds "all bugs" from simple prompts.

Is PHP2Shell being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on October 26, 2026. Amazon saw an attempt on October 17, before disclosure, and Dream reported an attacker who chained it with a Linux kernel bug to root 25 firewall management servers, three in a US government-affiliated network.

What is an AI exploit?

An AI exploit is an attack where AI models do part of the work of turning a vulnerability into working code, such as adapting it to versions and memory layouts. PHP2Shell shows both sides: Wiz used models to build exploits, and the attacker Dream tracked had Claude Code and AI-written scripts on their servers.

Am I affected by PHP2Shell if I don't write PHP?

Possibly. PHP ships inside control panels, vendor appliances, firewalls and Windows software, and the 25 servers rooted in October were firewall management systems running PHP 8.0.30. Check every image and appliance you run for a PHP binary, not just your own code.

Does updating WordPress fix PHP2Shell?

No. PHP2Shell is a bug in PHP, the runtime under WordPress, so only a PHP update fixes it. Your host may have already patched it. Kinsta, for example, patched PHP across its platform on October 21 and 22. Ask your host in writing if you can't confirm it.

Build the patch pipeline before the next one

PHP2Shell will not be the last old bug that a model makes cheap to exploit. The fix that held up was a patch pipeline someone had already built. If you're setting up agents to do that kind of work, start with compound engineering for Claude Code, and subscribe to the newsletter for the next one.