PHP2Shell Patch Guide: Fixed PHP Versions and a 10-Step Checklist

Updated 22 October 2026. PHP released fixes on 21 October 2026 for two critical vulnerabilities known as PHP2Shell; this page lists the fixed versions for each platform and walks through checking and patching a server.

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a web server without logging in. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Both are rated 9.2 on CVSS v4.0, and the PHP project says there are no complete mitigations: updating is the only safe choice.

The bugs are in PHP itself, not in WordPress, Laravel or your own code, so updating WordPress or a plugin does not fix them. Every PHP installation that serves web requests is at risk, with Apache mod_php the most exposed. If a host manages PHP for you, ask them to confirm the patch in writing. If you manage the server, update PHP, restart every PHP worker and verify, using the checklist below.

PHP2Shell at a glance

Question	Answer, as of 22 October 2026
CVEs	CVE-2026-109618 (code execution through out-of-memory corruption) and CVE-2026-109619 (code execution through stale global state)
Severity	Critical, CVSS v4.0 score 9.2 for both
Fixed versions	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026
Affected	Every version below those; Wiz traces the affected code back to PHP 5.4
Most at risk	Apache with mod_php; PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also listed
PHP 8.1 and older	No new release from the PHP project; use distribution backports, a vendor fix or the PHP team's source patches
WordPress update needed?	No. WordPress says no update is required or planned; PHP must be updated
Attacks	CISA had not seen exploitation when it published; Cloudflare reported attack traffic aimed at its customers

What PHP2Shell is, in plain English

Both bugs sit in code that PHP runs around each web request, before your application starts, which is why the framework or CMS on top does not matter.

CVE-2026-109618, out-of-memory corruption. If PHP runs out of memory while still setting up a request, it can leave half-built internal data that the cleanup code later treats as valid. The GitHub advisory says code execution was demonstrated on Apache mod_php with default limits; crafted multipart form requests are one way to hit the memory limit.
CVE-2026-109619, stale global state. A PHP worker can keep pointing at memory from a finished request, and a later request on the same worker can use it, a use-after-free. One confirmed path goes through session upload progress, which is on by default, even if your code never calls session_start().

The PHP Foundation says the security firm Calif, Wiz and OpenAI reported the root cause between August and September. Wiz says frontier AI models helped it build working exploits, including proof-of-concept attacks on WordPress, Drupal and Joomla container images. Details leaked on 20 October, so PHP moved the release forward to 21 October at 14:00 UTC.

Is my site affected? Check the PHP your web server runs

Assume yes until you have checked. Two things trip people up. First, php -v shows the command line binary, which can differ from the PHP-FPM pool or Apache module serving your site. Second, Linux distributions backport fixes without changing the upstream version number: Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13, so the version still starts with 8.3.6, far below 8.3.36, even though it is patched. Compare package versions with the table below, not the upstream number.

To see what the web server runs, upload a file with a random name, open it in a browser, then delete it:

<?php
echo PHP_VERSION . ' via ' . PHP_SAPI;

On Debian or Ubuntu, list the installed packages, and on Ubuntu search the changelog for the CVE numbers (change 8.3 to your version). Mattias Geniar notes that Debian and packages.sury.org changelogs may only mention a new upstream version, so compare version numbers there:

dpkg -l 'php*' | grep '^ii'
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

In WordPress, Tools, Site Health, Info, Server shows the PHP version, but with backported packages only your host can confirm the fix.

Fixed PHP versions by platform

Platform	Package	Fixed version
PHP source and Windows builds (php.net)	8.5, 8.4, 8.3, 8.2	8.5.12, 8.4.27, 8.3.36, 8.2.35
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 and 18.04	php7.4, php7.2	Fixed packages through Ubuntu Pro (ESM) only
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1 (DSA-6574-1)
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1 (DLA-4848-1)
Docker official image	php	Version tags such as 8.4.27-fpm, published 21 and 22 October

Checked against php.net, USN-8948-1, the Debian security tracker and Docker Hub on 22 October 2026.

The 10-step PHP2Shell patch checklist

1. List every server and container that runs PHP

CISA's alert asks organizations to find every system running PHP, including PHP bundled inside other software, and to patch internet-facing systems first. Include staging sites, old campaign sites, admin tools and CI images; a forgotten site on the same server can be the way in.

2. Note which PHP version and handler each site uses

Record each site's PHP branch and handler: PHP-FPM, Apache mod_php, LiteSpeed, FrankenPHP or php-cgi. The PHP advisory rates mod_php highest because a demonstrated exploit fires before any application code runs. Sites on PHP 8.1 or older need step 7 too.

3. Update PHP

On Ubuntu and Debian, a normal system update pulls in the fixed packages, as Ubuntu's notice says:

sudo apt update
apt list --upgradable 2>/dev/null | grep php
sudo apt upgrade

On RHEL, AlmaLinux or Rocky with the Remi repository, run sudo dnf upgrade 'php*'; Mattias Geniar reported that some Remi mirrors lagged and that sudo dnf clean metadata helps. On Windows, download the fixed build from php.net. In Docker, pin a fixed tag and rebuild with fresh base layers:

FROM php:8.4.27-fpm

docker build --pull -t my-php-app .

Then redeploy the containers, since running ones keep the old image.

4. Restart every PHP worker

Running processes keep the old code until they restart. Ubuntu says Apache must be restarted when PHP runs as mod_php, and Mattias Geniar adds that a reload or graceful restart is not enough:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Use your own FPM service name (php-fpm and httpd on RHEL-family systems), run sudo pkill lsphp for LiteSpeed, and restart long-running PHP processes such as Laravel Octane servers and queue workers. FrankenPHP needs a new release or image, not apt or dnf.

5. Verify the fix

Load your version script again and compare package versions with the table above. On Debian or Ubuntu, sudo needrestart -r l lists services still using old libraries, if the tool is installed. Note what you checked and when, in case a client or auditor asks.

6. On shared or managed hosting, get it in writing

On most shared hosting you cannot update PHP yourself, so ask your host which PHP builds your account uses, whether they include the 21 October fixes and whether workers were restarted. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr are already protected and need no action.

7. Get off PHP 8.1 and older

The PHP project releases nothing for 8.1 and older. Bridge options: distribution packages that carry the fix (Ubuntu 22.04's php8.1 is patched), Ubuntu Pro for 20.04 and 18.04, a commercial LTS vendor, or the PHP team's minimal source patches for 7.4, 8.0 and 8.1. Then upgrade: PHP 8.2 loses security support on 31 December 2026, so aim for 8.4 or 8.5, supported until the end of 2028 and 2029. WordPress recommends 8.3 or higher. If an old custom app holds you back, our guide on whether to rewrite or refactor helps you size the job.

8. Keep a web application firewall in front, but do not rely on it

Cloudflare put PHP2Shell rules live at 03:02 UTC on 21 October, before the release, and they are on by default for every plan with its WAF, including Free. Paid zones should confirm the Cloudflare Managed Ruleset runs in block mode. Cloudflare also saw attackers changing payloads to get around the rules, and a WAF only sees traffic that passes through it, so make sure your origin cannot be reached directly by IP address.

9. If you cannot patch today, apply the stopgaps

The php.net advisory lists settings that block known attack paths without making a server safe. Set them in php.ini or the FPM pool configuration, not with ini_set() or a .user.ini file, then restart every worker:

; Stopgaps from the php.net advisory, until PHP is updated
session.upload_progress.enabled = 0
; 8M if the site takes no uploads, 32M if it does
post_max_size = 8M
upload_max_filesize = 6M
; PHP 8.5 only
fatal_error_backtraces = 0

The advisory also suggests memory_limit=-1, set where apps cannot override it, with a container or cgroup memory limit as the safety net. CISA goes further: if you cannot update right away, or run PHP 8.1 or older, take PHP systems offline until they are patched.

10. Watch for signs of an attack

Wiz suggests watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies and unexplained PHP worker churn; CISA adds PHP workers that start shells or download tools. Check web server, PHP-FPM and system logs, since application logs may show little. If you find signs of compromise, isolate the server, restore a clean backup onto patched PHP and rotate every password and key the site could read.

Is PHP2Shell being exploited?

The picture is mixed. CISA said on 21 October that it had not observed exploitation when it published. Cloudflare said it saw attack traffic aimed at its customers, with payloads changed to get past its rules. The PHP Foundation said no functional exploits had been found at release, and developer Elias Taylor argued that the proof-of-concept code circulating on GitHub fails against a standard installation. Wiz notes that a working attack needs several bugs chained together and tuned to each server. Reliable attacks are hard, attackers are trying anyway, and the fix is a routine update, so patch now.

What this means for WordPress, Laravel and custom PHP sites

Whether you run WordPress, Laravel or a custom app, the framework version does not matter here; the PHP build does. What should change is the routine: keep PHP on a supported branch and know who patches it. Our website maintenance cost guide and app maintenance cost guide show what that care costs, and how to secure a web application covers the wider checklist. If constant patching wears you down, see our WordPress vs custom website comparison and our notes on VPS, serverless and managed hosting.

If you would rather hand this off, patching PHP, upgrading old branches and testing the site afterwards is routine web development work for us, quoted at a fixed price. Send us your server or hosting details and we will tell you what needs doing.

PHP2Shell FAQ

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both are rated 9.2 on CVSS v4.0 and can let an attacker who is not logged in run code on a web server through crafted requests. Because they are in PHP itself, every PHP application is exposed until its server runs a fixed build.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, fix both vulnerabilities. Linux distributions ship the fixes as backported packages, such as 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04 and 8.2.35-1~deb12u1 on Debian 12. PHP 8.1 and older get no new release from the PHP project, so those servers need a distribution or vendor backport, or an upgrade to a supported branch.

Do I need to update WordPress for PHP2Shell?

No. WordPress said on 21 October 2026 that no WordPress update is required or planned, because the flaws are in PHP, not WordPress, so updating WordPress, themes or plugins will not protect the site. Ask your host to confirm in writing that PHP was patched and restarted. On WordPress.com, WordPress VIP and Pressable, Automattic says nothing needs to be done.

Why does php -v still show an old version after patching?

Because distributions backport security fixes without changing the upstream version number. On Ubuntu 24.04 the fixed package is 8.3.6-0ubuntu0.24.04.13, so the version still starts with 8.3.6. Check the package version with dpkg or rpm and compare it with your distribution's security notice, or search the package changelog for the CVE numbers.

Is a WAF like Cloudflare enough to stop PHP2Shell?

No, but it helps while you patch. Cloudflare deployed rules by default for every plan with its WAF, including Free, on 21 October 2026. It also saw attackers changing payloads to get past those rules, and a WAF cannot protect traffic that reaches your server directly. PHP, CISA and Cloudflare all say updating PHP is the real fix.

What should I do if I am stuck on PHP 7.4 or 8.1?

Get a patched build first, then plan the upgrade. Ubuntu 22.04 ships a fixed php8.1 package, Ubuntu Pro covers 20.04 and 18.04, and the PHP security team published minimal source patches for 7.4, 8.0 and 8.1. If none of these fit, CISA advises taking the system offline until it is patched. Then move to PHP 8.4 or 8.5, since 8.2 loses security support at the end of 2026.

Sources

Editor's note: Facts checked against official announcements and documentation on 22 October 2026. These topics are moving fast; prices, availability and features may change.