php2shell on PHP 7.4, 8.0 and 8.1: what helps now

As of 25 October 2026. All times in UTC unless stated otherwise.

Against the critical flaws CVE-2026-109618 and CVE-2026-109619, known as php2shell, the PHP project released only four versions on 21 October: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates from the project. What has happened since the patch is in php2shell after the patch.

According to W3Techs, on 24 October 26.8 percent of PHP websites with a known version ran PHP 7 and 7.7 percent PHP 5. This article collects the routes available for these versions, what each of them demonstrably delivers and how to check whether your system is actually protected.

The key points

• The PHP team has published fixes for 7.4, 8.0 and 8.1 as source code, explicitly as a “Minimal mitigation for EOL version”. There are no new version numbers, tarballs or Windows builds for them.
• Debian (through Freexian), Ubuntu (through Ubuntu Pro), Red Hat and cPanel have shipped patched packages for older versions, in some cases down to PHP 5.5.
• Several German hosting providers have patched their old PHP versions too, including Hetzner, all-inkl and hosting.de.
• There is no fix in the official Docker images or in Google Cloud’s runtimes for 8.1 and older.
• The output of php -v does not tell you whether the fix is in.

Is my version affected at all?

The sources contradict each other here, which matters for scanners and audits:

A scanner that relies only on the CVE record may therefore report a PHP 7.4 installation as “not affected”. The PHP team, NVD and the distributions, on the other hand, treat these versions as affected and ship fixes for them.

Route 1: the distribution package

If PHP comes from your Linux distribution’s repositories, the fix arrives there, as long as the version is still maintained:

Two caveats: the Debian packages for 7.4 and older do not come from the regular Debian repositories but from Freexian’s Extended LTS archive. The Ubuntu packages for 20.04 and older are only available with an Ubuntu Pro subscription. If neither is set up, apt upgrade will not bring you the fix.

Route 2: the hosting provider

With shared hosting and managed servers, PHP is in the provider’s hands. What some hosts have said publicly about old versions:

This applies to the web hosting products. On your own virtual or dedicated server, you are responsible, as with route 1.

Route 3: building from the backports

The PHP team created three separate branches in php-src, each with a single commit from 18 October:

• PHP-7.4-CVE-2026-109618-109619 (commit 712e60f9edfd)
• PHP-8.0-CVE-2026-109618-109619 (commit 82f8f31b16a0)
• PHP-8.1-CVE-2026-109618-109619 (commit 1d7dec178a09)

The commit message reads “Minimal mitigation for EOL version”. According to php.net, the backports are meant “to help people building from source or without access to an LTS vendor”. What that means in practice:

• No new version. Tags such as php-7.4.34 or php-8.1.35 do not exist. A build from the 8.1 branch still reports itself as 8.1.34.
• No maintenance. On a failing test in the 7.4 branch (issue #24599), PHP developer Ilija Tovilo wrote: “7.4 is out of support. We only provided patches for these versions to help out distributions.” The issue was closed as “not planned”.
• A known pitfall when building. According to issue #24649, the 8.1 patch triggers regeneration of the Zend VM files. Using PHP 8.5 as the host PHP for this produces broken code. The answer in the issue: backport another commit or run the script with a lower PHP version, along with the remark that 8.1 is missing “many other patches”.

Route 4: a commercial LTS vendor

Zend (Perforce) writes on 22 October that it shipped patches to its PHP LTS customers “including PHP 7.2, 7.3, 7.4, 8.0, and 8.1” at the same time as the community release. They are obtained through the paid LTS service. Other vendors also advertise fixes for old versions; for them I have not found a primary source I could cite here.

Where there is no fix

• Official Docker images: the php:7.4, php:8.0 and php:8.1 images are no longer built. The docker-library/php project only carries 8.2 to 8.5, and the security commit of 21 October updates only those.
• Windows: windows.php.net has no builds for 7.4, 8.0 and 8.1 after 7.4.33, 8.0.30 and 8.1.34.
• Google Cloud: “Applications on PHP 5.5, PHP 7.2, PHP 7.3, PHP 7.4, or PHP 8.1 remain vulnerable and must be upgraded to PHP 8.2 or newer.”
• Laravel Vapor: according to Laravel, there is no patch for PHP 8.0 and 8.1.

How to tell whether the fix is in

The version number alone does not tell you. Ubuntu built the fix into a package carrying PHP 7.4.3, cPanel without a version change, and a build from the backport branch reports the old number. What counts is the package:

# Debian, Ubuntu: compare the installed package version with the table above
dpkg -l 'php7.4*' | grep ^ii

# RHEL and derivatives: search the changelog for the CVE numbers
rpm -q --changelog php-common | grep -E 'CVE-2026-(109618|109619)'

Check the version that actually serves web requests, that is PHP-FPM or the Apache module, not just the command line. For PHP you built yourself, the only proof is which commit it was built from.

What the official bodies recommend

• PHP team: ask your vendor or distribution about backported fixes “or upgrade to a supported version”.
• CISA: organizations running PHP 8.1 or older, or unable to update immediately, should take the systems offline until they can be patched or updated.
• Google Cloud: upgrade to PHP 8.2 or newer.

All the routes above close these two flaws. None of them brings the other fixes that have gone into PHP since the respective version reached its end of life. What moving to a maintained version involves is in PHP 7.4 to PHP 8.4. If you land on 8.2, you only have until 31 December 2026: PHP 8.2 end of life.

Frequently asked questions

Is PHP 7.4 affected by php2shell? According to NVD, yes, by both flaws. The PHP team published a dedicated backport for it. Only the CVE record does not list 7.4 as affected.

Is there a PHP 7.4.34 or 8.1.35? No. The PHP team has not released new versions for these branches, only source-code fixes.

My host shows PHP 7.4.33. Am I protected? The number does not tell you. What matters is whether the host has applied the fix. Several hosts have confirmed this publicly; if in doubt, ask.

Are the stopgaps from the advisory enough? According to the PHP team, they reduce exposure but do not make an installation safe. Only the fix helps completely.

Sources

• php.net: Security advisory of 21 Oct 2026
• php-src: backport branch 7.4, 8.0, 8.1
• php-src #24599, #24649
• GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
• CVE record CVE-2026-109618
• NVD: CVE-2026-109618, CVE-2026-109619
• Freexian: ELA-1853-1 php7.4
• Ubuntu: USN-8948-1, USN-8948-2
• Red Hat: CVE-2026-109618
• cPanel: EasyApache 4 change log
• Hetzner status (German)
• all-inkl: important information (German)
• hosting.de: PHP security update (German)
• Zend: php2shell patches now available
• docker-library/php: versions.json
• windows.php.net: archive
• Google Cloud: Responding to core PHP vulnerabilities
• Laravel: PHP critical vulnerability response updates
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• W3Techs: Usage statistics of PHP (as of 24 Oct 2026)

What an end of life means in general, and why it does not hurt on the date itself but at the next vulnerability, is in the glossary.