PHP2Shell: AI Turned a 20-Year-Old PHP Bug Into a One-Week Exploit
Two critical PHP vulnerabilities were patched today. The weakness was known for 20 years. What changed is the cost of weaponizing it.
- A PHP bug class sat unexploited for about 20 years. With frontier AI models, Wiz says, one researcher needed a week for what once took a team months.
- The target is the engine under about 70% of the web. Attacks were reported before the patch existed, and governments took sites offline on Oct 21, 2026.
- Update PHP now (last section) and rotate secrets if your server was exposed. 8.1 and older get no official fix.
For about 20 years, a flaw class in PHP sat in plain view, and nobody turned it into a weapon. Too slow, too much specialist work. Then frontier AI models entered the loop, and one researcher did in about a week what a world-class team would have needed months for.
PHP2Shell is not a new bug, it is a new price for old bugs.
The AI did the slow part: fail, read, adjust, retry
The week looked like this: Aug 19, a Wiz researcher finds the bug. Aug 20, it runs code on Drupal, no login needed. Aug 21, WordPress (Wiz). One researcher. Two days. Working code on both.
Each exploit meant chaining bugs and adapting to every target's memory layout, work Wiz calls “at the edge of what human researchers could practically achieve.” An attempt failed. The model read its own failure, adjusted its guess at the target's memory layout, tried again (SanSec summarizes the loop).
Three teams, Calif, OpenAI and Wiz, found it independently in the same weeks, and anyone with the same tools could have followed.
Known for 20 years, written off as too hard to exploit
In 2004, Stefan Esser found the first PHP memory-limit remote vulnerability and released no exploit. It was reported once in 2020, audited again in 2024, never proven (PHP Foundation). Known three times since 2004, never once proven.
SanSec's read on the whole story: what changed is the cost of weaponizing it. “Hard to exploit” was a price tag counted in specialist-months per target; models cut it to about a week, and that is what a small team can now afford to attack. Now it becomes easy with AI (pardon, SI).
CVE-2026-109618 and CVE-2026-109619: the engine under about 70% of the web
Wiz puts PHP at about 70% of websites; w3techs independently measures 69.3% of sites with a known server-side language.
The flaw is in the engine, not your code. Wiz showed that even a plain Hello World app is exposed. Calif, per SanSec, got pre-auth code execution on 11 applications, including WordPress 7.1.2.
The dark morning: attacks began before the patch existed
Cloudflare reported early attacks at 07:43 UTC on Oct 21, more than six hours before the patch existed.
The people closest to it did not wait. Tweakers, the Dutch House of Representatives, the National Cyber Security Centre and Security.NL went dark as a precaution. PHP core developer Gina Peter Banyard had called going offline the most sensible option before the release. Finland's Valtori pulled government web services offline, and Reuters reports the EU's ENISA warned sites may need to follow.
Details leaked on Oct 20, and watchTowr said it believed it had reproduced the bug; the PHP Foundation notes it had not identified a functional in-the-wild exploit at disclosure. But writeups and a public exploit tool are out, mass exploitation is expected, and the window is open now.
The boring part (for the sysadmins in the back): update PHP now
Every PHP version since 5.4 (2012) is affected by at least one of the two CVEs, unauthenticated remote code execution, default configs, mod_php and PHP-FPM alike. php.net rates mod_php the highest risk: an unauthenticated request can trigger the flaw before any application code runs.
- Patch: install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, released Oct 21 at 14:00 UTC (php.net advisory).
- Check: run
php -v; the CLI PHP may differ from the web-facing one, and a distro backport may keep the old version number, so the distro's security tracker is the reliable check. On shared hosting, ask your host when they patch; in Docker, rebuild on a patched base image. - Rotate: secrets on any server that was reachable before Oct 21. CVE-2026-109618 leaks freed worker memory (passwords, tokens, API keys, TLS keys), Heartbleed-style, inside a
PHPSESSIDresponse cookie, even if the app never callssession_start(), and attacks began before the patch. Check access logs for Oct 20 and 21 and look for new files in upload and temp directories. - Cannot patch yet: per the advisory, set
memory_limit=-1viaphp_admin_valueor the FPM pool (it removes the controllable memory-limit failure the attack needs), use a lowpost_max_size, setsession.upload_progress.enabled=0, then restart every worker. The advisory: “There are no complete mitigations, updating is the only safe choice.” - Unsupported: 8.1 and older get no official fix from the PHP project. Minimal source backports exist for 7.4, 8.0 and 8.1, and distro or LTS vendors may backport. PHP 8.2 reaches end of life on Dec 31, 2026. Remi repo users: the volunteer rpm repo has no update today, so switch to distro packages or build from source.
- WAF stopgap: Cloudflare's WAF rules went live for all plans from about 03:02 UTC on Oct 21, as defense in depth while you patch.
The price of exploiting old bugs has dropped. This week, re-score every finding you deferred as “hard to exploit.”
FAQ
What is PHP2Shell?
PHP2Shell is the name for two critical bugs in the PHP engine that let an unauthenticated attacker run code on a server. PHP released fixes on Oct 21, 2026.
Which CVEs does PHP2Shell abuse?
CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2 and both remote code execution without a login. The first also leaks memory through a PHPSESSID cookie; the second leaves stale state in the worker.
Which PHP versions are affected?
Every PHP version back to 5.4 (2012) is affected by at least one of the two bugs. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP 8.1 and older get no official fix, though vendors may backport.
Is WordPress affected by PHP2Shell?
Yes, through the PHP engine underneath it. Wiz demonstrated unauthenticated remote code execution on WordPress, and SanSec reports Calif confirmed it against WordPress 7.1.2. Updating PHP is the fix.
Are Cloudflare's WAF rules enough protection?
No. Cloudflare calls its WAF rules a stopgap, and the php.net advisory says: “There are no complete mitigations, updating is the only safe choice.”
Sources are linked inline; the SanSec, Wiz and php.net posts are dated Oct 21, 2026.
The full run is on our home timeline; where the word SI comes from is in our definition post.