PHP2Shell: Patch PHP Today, Then Find the PHP You Forgot

As of October 22, 2026.

If a server runs PHP and answers web requests, patch it today. Then go looking for the PHP you did not know you ran, because that is where the damage will land.

What happened

On October 21 the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two bugs it rates 9.2 on CVSS v4.0. Both allow unauthenticated remote code execution.

• CVE-2026-109618: an out-of-memory error can interrupt PHP while request data is half built, and cleanup then treats the bad data as valid.
• CVE-2026-109619: request state can outlive the memory behind it, and the next request on the same worker can use it.

The bugs live in the engine, so the application code does not have to be at fault. PHP says the risk is highest under Apache mod_php, where a demonstrated exploit fires before any application code runs.

AI found them. Ryan Austin of Calif found them in August using OpenAI's GPT-5.6 Sol, as part of OpenAI's Patch the Planet program. Wiz Research also worked the bugs with frontier models and says its team found them on August 19 and told PHP on August 24. Wiz traces the flawed code back to PHP 5.4, released in 2012.

Disclosure did not go to plan. Details leaked before the patch, and a public exploit appeared hours before the release. Cloudflare turned on WAF rules for free and paid plans at 03:02 UTC on October 21, about nine hours ahead of disclosure, and saw attack traffic against its customers in that window. watchTowr has since seen both CVEs exploited in the wild through its honeypots. As of October 22, CISA has not added either CVE to its Known Exploited Vulnerabilities catalog.

The response has been unusually blunt. The UK NCSC says to consider taking a system offline if you cannot update it, and CERT-EU says to consider isolating internet-facing apps until a fix is applied and verified. The BBC reported that Finland's government, the Wikimedia Foundation, the Dutch parliament and the Dutch public health institute RIVM took sites offline, and that BBC programme pages, Edinburgh council and DeviantArt had pages down, though not every outage was tied to PHP. Wiz puts the share of the internet affected at "roughly 70%", a figure the BBC could not verify.

Who is exposed

PHP's advisory covers every installation that serves web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Your own code being clean does not help.

The PHP you track is the easy part. The risk sits in PHP nobody counts as PHP:

• CMSes and shops. WordPress, Drupal, Joomla, Magento and Nextcloud all run on the engine. Sansec lists them among affected platforms.
• Hosting panels and shared hosts. cPanel and similar tools run PHP for their own admin pages, often on a version the host picks.
• Container images. A php:8.3-fpm base image from last month still has the old engine. Pulling a fixed package does nothing to an image already built.
• Appliances and vendor products. Routers, NAS boxes, VPN portals, monitoring tools and on-prem SaaS often ship a bundled PHP you cannot see or patch yourself.
• Old branches. PHP 8.1 and older get no fix from the PHP project. watchTowr says PHP 5 is affected too.

What to do now

1. Find every PHP runtime. Check hosts, containers, images in your registry, CI images and appliances. The NCSC says not to stop at outdated versions: find PHP in general, internet-facing first. On a host, php -v covers the CLI; check FPM and mod_php packages too, since they can differ.
2. Patch to a fixed version. Use 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distro's backport. Ubuntu has fixes back to 14.04 (older releases need Ubuntu Pro). Debian, RHEL and Alpine have shipped updates too. On 8.1 or older, upgrade, or get a backport from your distro or an LTS vendor; PHP has posted minimal source backports for 7.4, 8.0 and 8.1.
3. Restart and rebuild. A new package does nothing until the old workers die. Restart Apache or PHP-FPM, rebuild and redeploy container images, and confirm the running version, not the installed one.
4. If you cannot patch today, block multipart/form-data at the web server. Sansec and Cloudflare describe this stopgap. It covers only part of the attack, and it breaks file uploads, such as product images in a Magento admin. Match the comma variant too (multipart/form-data,boundary=x), which PHP still parses. PHP's advisory also lists config changes, such as session.upload_progress.enabled=0, and says plainly that none of them fully mitigates the bugs. Remove the block once you have patched.
5. Assume breach on anything exposed before you patched. watchTowr lists what to look for: new web shells and files written to web roots, new accounts, unexpected cron jobs, outbound connections from PHP processes you cannot explain, and PHP workers that crashed or hit memory limits after large multipart requests.
6. Watch your vendors. Appliances and hosted products will patch on their own schedule. Ask each vendor whether they ship PHP and when the fix lands, and keep the stopgap in front of them until it does.

The gap is now hours

The code at fault has been in PHP for about fourteen years. Frontier models found it, and Wiz says they "substantially reduced that barrier, turning a longstanding flaw into an exploit." Then the details leaked, a public exploit landed before the patch, and attacks began before most teams had read the advisory.

That window will keep shrinking. When a working exploit can show up before the patch does, the slow step is no longer the patch. It is working out where the vulnerable thing runs. An inventory built after the advisory is built too late, so the list of every runtime, image and appliance has to exist before the next one.

Where Rafter fits

Rafter scans code, not servers, so it will not tell you which PHP version your fleet runs. rafter run sends a repository to a remote audit that pairs agentic review with SAST and dependency scanning, and the free local CLI catches secrets before they are committed and gates risky commands from coding agents. Neither replaces the runtime inventory above; that part is yours.