Still on PHP 7.4, 8.0 or 8.1? How to Handle PHP2Shell When PHP Ships No Fixed Release No PHP2Shell release exists for PHP 7.4, 8.0 or 8.1, only source backports. How to choose: upgrade, vendor packages, build from the backport, or go offline.
Still on PHP 7.4, 8.0 or 8.1? How to Handle PHP2Shell When PHP Ships No Fixed Release
On October 21, 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close PHP2Shell (what the flaws are ). There is no new 7.4, 8.0 or 8.1 release, because all three branches are past end of life. Teams maintaining these systems have to pick one of the options below.
Short answer: The PHP security team published source backports for 7.4, 8.0 and 8.1, but no releases and no new version numbers. Work down this list:
Upgrade to a branch that still gets security fixes, if you can.
Otherwise, install a fixed package from your distro or vendor.
Otherwise, if your team already builds PHP from source, build from the official backport.
Otherwise, take the system offline, as CISA advises, or isolate it from public networks, as the Canadian Centre for Cyber Security advises.
While you can't update, use step 4 in the meantime rather than waiting for steps 1 to 3 to fail. On 8.2, install 8.2.35 now, but plan the next move: 8.2 reaches end of life on December 31, 2026.
Step 1: Which branch to move to (php.net's dates)
If you are leaving 7.4 or 8.1, aim for 8.3 or later, and 8.4 or 8.5 if you can. Moving to 8.2 now buys about two months. The main migration task is testing your application on the new PHP, which this guide doesn't cover.
The PHP2Shell CVE records list only 8.2 to 8.5 as affected. For 7.3 and older, third parties watchTowr and Tenable assess them as affected too, and PHP has published no fix. Dates below are from php.net as of October 25.
Branch Status (php.net) Security fixes until Last release PHP-project release or source backport 7.2 and older End of life — — No PHP-project fix 7.3 End of life Dec 6, 2021 — 7.3.33 No PHP-project fix 7.4 End of life Nov 28, 2022 — 7.4.33 Source backport only 8.0 End of life Nov 26, 2023 — 8.0.30 Source backport only 8.1 End of life Dec 31, 2025 — 8.1.34 Source backport only 8.2 Security fixes only Dec 31, 2026 8.2.35 Fixed release 8.3 Security fixes only Dec 31, 2027 8.3.36 Fixed release 8.4 Active support until Dec 31, 2026 Dec 31, 2028 8.4.27 Fixed release 8.5 Active support until Dec 31, 2027 Dec 31, 2029 8.5.12 Fixed release
If your servers are spread across so many branches that this table is hard to track by hand, see plans and pricing before you decide.
What the source backports are, and why the version number doesn't change
php.net says that, given the severity, the security team provided "minimal source-backports" for 7.4, 8.0 and 8.1 "to help people building from source or without access to an LTS vendor". They live in three php-src Git branches: 7.4 , 8.0 and 8.1 .
Each branch adds one commit, "Avoid state corruption via bailout". Its message reads "Minimal mitigation for EOL version." and lists fixes for both CVE-2026-109618 and CVE-2026-109619, so one commit covers both.
What doesn't exist is a release: no new tag, no tarball, and PHP's two advisories list patched versions only for 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
So the version string is not evidence. The backport commit doesn't touch version files. Build the 8.0 or 8.1 branch and configure.ac still says 8.0.30 or 8.1.34, so phpversion() returns exactly what it returned before. The 7.4 branch carries 7.4.34-dev, left over from a 2022 commit, which isn't a release either.
Vendor packages are similar: the upstream version may stay the same while the package release ID changes, such as Synology's 8.1.34-0120, and Plesk keeps the number but changes the build date.
Step 2: Install a distro or vendor fix
This table is what the vendors' own pages showed on October 25, 2026. The vendor's current advisory is the source of truth : check the linked advisory before you act. This also applies to the "not confirmed" and "no fix" lists below.
Source Legacy branches fixed How to check Ubuntu 22.04 (free) php8.1 8.1.2-1ubuntu2.28 or later Ubuntu Pro (ESM) php7.4 (20.04), php7.2 (18.04), php7.0 (16.04), php5 (14.04) e.g. php7.4 7.4.3-4ubuntu2.29+esm5 Red Hat (RHSA-2026:87080 , RHSA-2026:87151 ) php:7.4 module on RHEL 8, php 8.0 on RHEL 9 Package version in the RHSA AlmaLinux Every PHP stream on 8, 9 and 10 Compare rpm -q php-common with the notice (PHP 8.4 on AlmaLinux 10: rpm -q php8.4-common) cPanel EasyApache 4 ea-php74, ea-php80, ea-php81 25.91 documents the backport; 25.92 rebuilt ea-php74-meta, ea-php80-meta and ea-php81-meta so their changelogs list it CloudLinux alt-php 5.2–5.6, 7.0–7.4 and 8.0–8.5; ea-php52 through ea-php85 alt-php package changelog (command below) Plesk for Linux 7.4.33, 8.0.30, 8.1.34 Build date October 21, 2026 or later DirectAdmin CustomBuild 8.1, 8.0, 7.4, then 7.3, 7.2, 7.1, 7.0 and 5.6 A * after the version Synology PHP 7.4, 8.0, 8.1 packages 7.4.33-0131, 8.0.30-0122, 8.1.34-0120 or later
For CloudLinux alt-php packages, CloudLinux's check (read-only; change the version in the package name) should return both CVEs:
rpm -q --changelog alt-php74-common | grep -E "CVE-2026-(109618|109619)"
The exception is native PHP 8.2 and 8.3 packages rebased to 8.2.35 or 8.3.36, whose changelogs don't name the CVEs; check the version with rpm -q php-cli instead. These commands read the installed package, not the runtime your site is actually using.
Update steps are in updating PHP on hosting panels and on your own server . For PHP inside an appliance, see products that bundle PHP ; Check Point's hotfix, for example, implements PHP's 7.4 fix.
Not confirmed: new php7.4, 8.0 and 8.1 builds on Ondřej Surý's Launchpad PPA, whose build changelog says only "No-change backport". The deb.sury.org package index has entries dated October 21, but they don't establish CVE coverage. Remi, Freexian ELTS, TuxCare ELS and ZendPHP LTS are said to have fixes only by Sansec. If you rely on one, get written confirmation that its package fixes both CVEs.
No fix (as of October 25): the official Docker php:8.1 and php:8.0 images had not been rebuilt, and Azure App Service says end-of-life PHP versions won't get these patches.
Step 3: Build from the backport, only if you already do this
This is the riskiest path, meant only for teams that already build and maintain PHP from source. If your PHP came from a distro package, don't overwrite it with a hand build. This guide gives no build commands; experienced teams should follow the php-src README and keep to these rules:
Build with your existing options. The PHP manual says php-config --configure-options returns the options to recreate the installed PHP's configuration.Build from the right branch and record provenance. The backport commits are 1d7dec178a094e6e75b229ce22754045f8c6070a (8.1), 82f8f31b16a035c1b67cc253e79f7cc288f4cc20 (8.0) and 712e60f9edfd03f0960fc4fc3c2c375f42b90aa2 (7.4). Store the commit SHA with the build, because the version string will never tell anyone.Test on staging before deploying.
To check a source tree you built from, this read-only command exits with status 0 when that commit is an ancestor of HEAD, per the Git documentation:
git merge-base --is-ancestor 1d7dec178a094e6e75b229ce22754045f8c6070a HEAD && echo "commit is an ancestor of HEAD"
That proves commit history only. It doesn't show that the change wasn't reverted, that the working tree matches what was built, or that the running binary came from this tree, so keep the build record and the web-side check as separate requirements. Bitdefender sees moving to a supported branch as the only reliable answer.
Step 4: Take offline or isolate while you can't update
CISA's alert (revised October 23) says organizations that cannot update immediately, "or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated", and that a web application firewall "may provide some protection". It doesn't mention backports. The Canadian Centre for Cyber Security advises isolating internet-facing applications from public networks until a fix is applied.
PHP's temporary settings reduce exposure on specific paths but don't make an installation safe. See how far a WAF gets you before you patch , and on any host exposed since October 17, hunt for PHP2Shell in your logs .
Confirm it worked
Restart every PHP worker. ThaiCERT says to restart PHP-FPM, Apache or LiteSpeed so the fixed binary loads.Check the runtime from the web side, as in checking the PHP version each site really runs , and match it to the verified package or build record, since the upstream version may not change. On Linux hosts with systemd, the service start time from systemctl status <service> is supporting evidence only: it doesn't show that every worker restarted or which binary serves which site.Keep evidence per host: the package version or build date, the vendor notice or commit SHA, and the web-side check.
If you still run an old AppServ install
The latest AppServ, 9.3.0 (September 29, 2019), ships PHP 7.3.10. There is no newer AppServ release and PHP published no source backport for 7.3, so neither an AppServ update nor step 3 exists. Some step 2 vendors ship fixed 7.3 packages, but we haven't verified whether any can replace an AppServ stack. The clear path is moving to a supported PHP and keeping the machine off the internet until then. Updating PHP on your own server covers moving off AppServ and XAMPP.
What this guide does not cover
Whether a vendor's backport is complete; only the vendor can attest to that
A backport closes these two CVEs only; the branch is still end of life
These steps tell you whether you are patched, not whether you were compromised first. If in doubt, see what to do when a PHP site may be compromised
Next round: 8.2 ends December 31, 2026
This job comes back when 8.2 reaches end of life. Write down now which branch each server runs, which package it comes from and when that branch ends, and the next round can start the same day. If you'd rather not keep that list by hand, zcrX tracks product lifecycle and end of life per software product, though it does not replace the patch or the branch upgrade.
📞 Free Consultation
zcr provides the software; hands-on migration or build work is delivered through channel partners.
Related articles
Sources
PHP News Archive 2026 — fixed releases, 7.4/8.0/8.1 source backports and their purpose, 8.1 and older no longer updated by PHP, 8.2 end of life, temporary settings that don't make an installation safePHP — Supported Versions and PHP — Unsupported Branches — branch dates and last releasesphp-src on GitHub: branches PHP-7.4 , PHP-8.0 , PHP-8.1 and commit 1d7dec1 (8.1) — commit message, version in configure.ac
GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — patched versionsphp-src README — Building PHP source code , PHP Manual — php-config and Git — git-merge-base CISA — Critical Vulnerabilities in PHP Require Immediate Patching — 8.1 and earlier, WAFCanadian Centre for Cyber Security AL26-026 — isolating internet-facing applicationsUbuntu USN-8948-1 and USN-8948-2 ; Red Hat RHSA-2026:87080 and RHSA-2026:87151 ; AlmaLinux cPanel EasyApache 4 change log , CloudLinux status , Plesk , DirectAdmin forum (staff) , Synology-SA-26:14 Check Point sk1000302 Launchpad — ppa:ondrej/php , deb.sury.org and Sansec — PHP2Shell — unconfirmed sourcesDocker Hub — php and Azure App Service Bitdefender — PHP2Shell technical advisory watchTowr — PHP2Shell and Tenable — PHP2Shell FAQ — 7.3 and olderThaiCERT — PHP2Shell advisory (Oct 22, 2026, Thai) — restarting workers after the updatesystemctl(1) — the status commandAppServ — Download — AppServ 9.3.0, PHP 7.3.10, 2019-09-29 Products | Pricing | Resources | Insights | Contact 