PHP2Shell: what it is and how to patch your site

On October 21, PHP shipped four releases on the same day: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Each one carries the same line on php.net: “There are no complete mitigations, updating is the only safe choice.”

The two bugs are CVE-2026-109618 and CVE-2026-109619, and the security press is calling them PHP2Shell. watchTowr’s FAQ lists both at 9.2 out of 10. Either one can let someone with no login run code on a server that answers PHP requests. That covers WordPress and WooCommerce, Laravel apps, sites on shared hosting, and PHP running in a Docker container. Each one gets patched a different way, so this guide takes them one at a time.

TLDR

PHP2Shell is two serious PHP bugs, patched on October 21, that let an attacker run code on a server without logging in. Any PHP below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 needs updating today, and PHP 8.1 or older has no official release at all. WordPress owners check Site Health and ask their host. Laravel teams patch each PHP version on the server and restart long-running workers. Docker users rebuild on the new official images. A static Astro site runs no PHP, so it has nothing to patch.

What happened

The PHP project’s two advisories on GitHub explain the bugs in plain terms. CVE-2026-109618 is a fault in how PHP cleans up after running out of memory while a request is half set up. CVE-2026-109619 leaves state from one request pointing at freed memory, which the next request on the same worker can then use.

You don’t need to follow the memory details to see the problem. Both bugs live in PHP itself, before WordPress, Laravel or any other code gets a chance to run. PHP’s release notes rate the risk highest for Apache with mod_php, where a request can trigger the attack before any application code runs.

CISA’s October 21 alert says the flaws “affect all PHP installations serving web requests” and asks organizations to patch immediately. Reports on attacks differ. Help Net Security reports that Amazon’s honeypots recorded an exploitation attempt on October 17, four days before the bugs were public, and watchTowr says it has seen attempts against both bugs since. CISA said it had not seen exploitation when it published. Patching doesn’t wait on which of those turns out right.

The versions that are safe

The last row is the one that worries us. PHP 8.1 and older don’t get releases from the PHP project any more. Its team published minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions ship their own fixes, but a site on an old shared host has no update button to press. CISA’s advice for systems on 8.1 or older that can’t be updated is to take them offline until they can be.

One trap applies to every setup below. The PHP your web server runs and the PHP you get when you type php -v in a terminal can be different installs. A server with PHP-FPM runs one process per installed version. Check the version that answers web requests.

WordPress and WooCommerce

WordPress shows its PHP version on the Site Health screen. Go to Tools, then Site Health, open the Info tab, and expand Server. That line is the PHP serving your pages, which makes it the one that matters.

The old-version row is not small for WordPress. WordPress.org publishes the PHP versions its sites report, and on October 22 its stats showed about 36 percent of WordPress sites on PHP 8.1 or older. Version 7.4 alone was close to 16 percent.

On managed WordPress hosting, PHP is usually the host’s job. On shared hosting or a server you manage yourself, it may be yours. Either way, send this:

Our site runs on PHP [your version]. Has it been updated for CVE-2026-109618 and CVE-2026-109619? If so, which version is running now, and have PHP-FPM or Apache been restarted so the new version is the one serving requests? If not, when will it be?

Then check Site Health again once they reply. A patched package that hasn’t been restarted is still running the old code in memory.

Laravel

A Laravel app usually runs on a server you or your team control, so the patch is yours to apply.

On Laravel Forge, open the server, go to the Runtime tab, then PHP. Each installed version has a menu with an Update option that moves it to the latest patch release. Forge runs a separate PHP-FPM process for every installed version, so patch each one, not only the default. Forge’s docs warn that a patch update can mean a few seconds of downtime. Forge also only knows about PHP it installed, so anything added by hand on the same server needs patching by hand.

On a server without Forge, update PHP through whatever installed it, usually the system package manager, then restart PHP-FPM for each version. Check the result with the FPM binary for that version, not just the php command.

Laravel Octane needs one more step. Octane keeps the same PHP workers alive between requests, through Swoole, RoadRunner or FrankenPHP, which is exactly the kind of setup CVE-2026-109619 is about. Updating the PHP package doesn’t replace code already running in memory. Restart the Octane server process, or redeploy the container, so every worker starts on the patched build.

A Laravel app is an app, with logins, queues and a database, so moving it to a static site isn’t the answer here. Keeping PHP current is, and it’s part of what our Care retainer covers on the custom builds we run in Laravel.

Shared hosting and cPanel

On shared hosting you can’t install PHP, but you can usually see and choose the version. In cPanel, the MultiPHP Manager lists each domain with its current PHP version and lets you pick another one the server has installed. cPanel’s docs say that if a version is missing, the server administrator has to install it.

That gives you two jobs. If a domain is on 8.1 or older and the menu offers 8.3 or 8.4, switch to it, then click through the site’s main pages and the contact form, because old plugins and themes can break on a newer PHP. Then ask the host the same question as above: have the PHP builds on this server been updated for CVE-2026-109618 and CVE-2026-109619? The fixed patch level comes from the host’s packages, not from the menu. Plesk has published its own support article for the PHP it ships, which is worth sending to your host if it runs Plesk.

Docker

The official PHP images on Docker Hub were rebuilt on October 21. The 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags exist, and moving tags like 8.4-fpm and 8.4-apache were updated the same day.

A running container doesn’t change when the image does. Rebuild your app image with a fresh base, then redeploy:

docker build --pull -t your-app .

The --pull flag makes Docker fetch the newest version of the base image instead of reusing the copy it cached weeks ago. If your Dockerfile pins an exact patch tag, such as php:8.4.25-fpm, change it to 8.4.27 first. Then confirm inside the running container:

docker exec your-container php -v

Images built on another base, such as a distribution’s own PHP packages, get the fix when that distribution ships it, so check its security notices.

Why a plugin or a firewall is not the fix

A WordPress security plugin or a Laravel middleware is PHP code that runs after PHP has already handled the request. These bugs happen before that, so the plugin never sees the attack. A firewall in front of the site is different. Cloudflare’s CTO told Help Net Security that “PHP sites behind Cloudflare already have an initial set of WAF rules deployed”, including on free accounts. That buys time against known attack patterns. It doesn’t change the PHP running underneath, and new variations of an exploit are exactly what a rule written yesterday can miss.

Where a static site sits

This site is built with Astro. Every page is turned into a plain HTML file when the site is built, and those files are served from a CDN. There is no PHP on the server, no database, and no admin login on the public address. When PHP2Shell went public, there was nothing here to update. The Astro vs WordPress comparison covers the rest of the differences, editing included.

That isn’t a claim that static sites can’t be attacked. The build tools still need updates, the hosting and domain accounts still need strong logins, and an Astro site that renders some pages on a server for bookings or logins runs JavaScript there, with its own updates to keep. What disappears is the layer that broke this week: a language runtime answering every request for every page, on a server someone has to patch the same day.

Patch now, then decide

Today’s job is the patch, whatever the site is built on. Once it’s done, the question is whether each site needs PHP at all.

A WooCommerce store does, and so does a Laravel app. Products, carts, orders, logins and queues run on PHP, so the answer is to keep it current and watched, which is what the Care retainer on our WooCommerce stores and Laravel builds is for. A brochure site with service pages, a blog and a contact form usually doesn’t. It runs PHP on every visit to show pages that change a few times a month.

If yours is the second kind, moving it to Astro without losing rankings explains the redirects and the metadata. The Astro website service does the move for a fixed price from $1,500, and the next PHP emergency becomes something you read about instead of something you fix.

Questions