PHP2Shell on Legacy Linux: Where to Find the Fix

Our first PHP2Shell article had a simple recommendation: update PHP immediately. That remains correct. It is also much easier to say when the server runs a supported operating system and a current PHP branch.

Reality contains CentOS 7, PHP 5.6, applications that require PHP 7.0, and one important website whose original developer has apparently joined a monastery without internet access. This follow-up is for those systems.

CVE-2026-109618 and CVE-2026-109619 affect PHP installations serving web requests and can lead to unauthenticated remote code execution. Upstream fixes are available in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older branches need a backport from an operating-system vendor, an extended-support provider, or a trusted third-party repository.

The package situation below was checked on October 23, 2026. Repositories are still changing, so follow the linked vendor notices before maintenance.

First, find out who supplied your PHP

Do not add a new repository until you know where the current packages came from. PHP may be supplied by the operating system, Remi, GetPageSpeed, Ondřej Surý’s repository, a hosting panel, a container image, or an appliance vendor. Mixing package families during an emergency is an excellent way to replace a security incident with a dependency incident.

On RPM-based systems, start with:

rpm -qa | grep -E '^php|^remi|^plesk-php|^alt-php'
dnf module list php 2>/dev/null

CentOS 7 uses yum, and yum repolist helps identify enabled third-party repositories. On Debian and Ubuntu, use:

dpkg -l 'php*' | grep '^ii'
apt-cache policy php php-fpm php-cli

Also check containers, cron jobs, command-line tools, and control panels. Updating /usr/bin/php does not update a PHP binary embedded in another product.

CentOS 7 and old PHP branches

CentOS 7 reached end of life in June 2024. Its official repositories will not suddenly return with a PHP2Shell patch, and Remi also stopped producing new EL7 builds in June 2024. A normal yum update against those old repositories is therefore not enough.

The best fix is to migrate the application to a supported operating system and current PHP branch. When that cannot happen today, GetPageSpeed provides free EL7 packages with PHP2Shell backports for PHP 5.6, 7.0, 7.3, 7.4, 8.0, and 8.1, plus a current PHP 8.4 build. The packages retain Remi-compatible names and paths and are designed to replace the corresponding Remi packages in place.

Before changing repositories, confirm that you have a current backup and a way to roll back the server. If possible, test the package replacement on a copy of the system first. Legacy applications sometimes contain extensions with equally legacy opinions about change.

For base-name packages, choose the channel matching the installed branch. This example is for PHP 7.0:

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php70 upgrade 'php-*'
systemctl restart php-fpm

Replace php70 with the exact channel for the installed version. Remi Software Collection packages have versioned names and services. For PHP 7.4, for example:

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum upgrade 'php74-php*'
systemctl restart php74-php-fpm

If the server uses Apache mod_php, restart httpd instead. Confirm package names before copying either example: base-name packages and Software Collections are different layouts.

These builds provide a practical emergency path, but GetPageSpeed is a third-party repository, not CentOS or the PHP project. Review its signing, repository, compatibility, and validation information as you would for any supplier whose code will run on a production server.

Most importantly, a patched PHP 5.6 on CentOS 7 is still PHP 5.6 on CentOS 7. The backport addresses these vulnerabilities and other fixes included by the packager; it does not restore full vendor support to the entire operating system or promise fixes for the next PHP bug. Patch now, then migrate.

Old Ubuntu releases have an official route

Canonical has released fixes for every Ubuntu generation it currently covers. USN-8948-1 lists the updates in the standard security repositories for supported releases:

• Ubuntu 22.04: PHP 8.1 package 8.1.2-1ubuntu2.28
• Ubuntu 24.04: PHP 8.3 package 8.3.6-0ubuntu0.24.04.13
• Ubuntu 26.04: PHP 8.5 package 8.5.4-0ubuntu1.5
• Ubuntu 26.10: PHP 8.5 package 8.5.9-0ubuntu2.1

The fixed package may retain an older-looking upstream version because Canonical backports security changes. Compare the complete Ubuntu package revision, not only the output of php -v.

For older systems, the updates are available through Ubuntu Pro and Expanded Security Maintenance, as documented in USN-8948-2:

• Ubuntu 14.04: PHP 5.5 5.5.9+dfsg-1ubuntu4.29+esm18
• Ubuntu 16.04: PHP 7.0 7.0.33-0ubuntu0.16.04.16+esm22
• Ubuntu 18.04: PHP 7.2 7.2.24-0ubuntu0.18.04.17+esm14
• Ubuntu 20.04: PHP 7.4 7.4.3-4ubuntu2.29+esm5

After enabling the appropriate Ubuntu Pro service, use the normal package manager:

sudo apt update
sudo apt upgrade

If PHP came from ppa:ondrej/php or packages.sury.org, do not expect Ubuntu’s package to replace it. Those repositories now have patched builds for PHP 5.6 through 8.5 on common supported Ubuntu and Debian combinations, although architecture coverage has been arriving at different times. Update from the same repository and verify that it offers a PHP2Shell-fixed package for your exact OS, architecture, and branch.

Debian: easy on 12 and 13, less easy before that

Debian has issued official updates for its current releases:

• Debian 12 Bookworm: PHP 8.2 is fixed in 8.2.35-1~deb12u1 under DLA-4848-1.
• Debian 13 Trixie: PHP 8.4 is fixed in 8.4.27-1~deb13u1 under DSA-6574-1.

Install the normal security updates, restart the relevant service, and verify that the fixed package revision is installed:

sudo apt update
sudo apt full-upgrade
dpkg-query -W 'php*' 2>/dev/null | grep -E 'php8\.[24]'

Debian 11 Bullseye left regular LTS support on August 31, 2026. PHP 7.4 fixes are available through Freexian’s paid Extended LTS service, while Debian 9 and 10 have corresponding ELTS backports for their PHP branches. Without ELTS, a maintained third-party repository, or your own properly reviewed build, these releases do not have a normal Debian security channel carrying the fix.

Ondřej Surý’s packages.sury.org is another option for legacy PHP on supported Debian releases. It should not be used to pretend that the underlying Debian release is still supported. If both the OS and PHP are obsolete, replacing both is generally safer than constructing an archaeological layer cake of repositories.

Current distributions: where updates stand

For reasonably current systems, the situation is much better.

Red Hat Enterprise Linux and CentOS

Red Hat has published fixes for most supported PHP streams on RHEL 8, 9, and 10. According to the package status checked on October 23, the remaining exception was the PHP 8.4 module stream on RHEL 9. Administrators using that stream should check the live Red Hat PHP2Shell bulletin before declaring the job complete.

Run dnf update, restart PHP-FPM or Apache, and compare installed packages with Red Hat’s CVE and errata pages. Retired streams remain a trap: PHP 7.2, 7.3, and 8.0 streams on RHEL 8 and PHP 8.1 on RHEL 9 have ended their application-stream life cycles.

CentOS Stream users should update from their enabled Stream repositories and verify the resulting build against the current package and CVE information. CentOS Stream 8 and CentOS Linux 7 are end of life and should not be treated as maintained systems. If PHP came from Remi instead of the distribution, Remi has fixed PHP 8.2 through 8.5 and backported the fix to 7.4, 8.0, and 8.1 for current Enterprise Linux releases. Remi’s PHP 7.2 and 7.3 builds do not have this fix.

AlmaLinux

AlmaLinux took the unusual but welcome step of patching every PHP stream it ships on AlmaLinux 8, 9, and 10, including several retired streams. The packages are now in production repositories, and a normal update should install them:

sudo dnf update 'php*'
sudo systemctl restart php-fpm

The AlmaLinux PHP2Shell announcement lists the exact corrected revisions. AlmaLinux also warns that emergency fixes for retired streams are not guaranteed in the future. If dnf module list php shows PHP 7.2, 7.3, or 8.0 on AlmaLinux 8, or PHP 8.1 on AlmaLinux 9, install this fix and schedule a move to a supported stream.

Ubuntu and Debian

Ubuntu 22.04, 24.04, 26.04, and 26.10 have official corrected packages. Ubuntu 20.04 and older need Ubuntu Pro for the Canonical-provided fix. Debian 12 and 13 are fixed through their security repositories. On either family, remember that a backported package may not display the newest upstream PHP version.

Arch Linux

Arch moved quickly. Its regular php package is fixed in 8.5.12-1, while php-legacy is fixed in 8.3.36-1. The Arch security tracker marks both packages fixed. Perform a complete system upgrade rather than a partial package upgrade:

sudo pacman -Syu

Then restart PHP-FPM, Apache, or every other long-running process that embeds PHP.

Updating the package is not the final step

Whatever the distribution, complete the job in this order:

1. Confirm where every PHP installation comes from.
2. Install the fixed package from that same trusted source.
3. Restart PHP-FPM, Apache, application workers, and containers.
4. Check the package revision and the PHP instance actually serving requests.
5. Review logs and the system for signs of compromise from the period before the update.
6. Test the application, scheduled jobs, extensions, uploads, sessions, and monitoring.
7. Keep temporary mitigations in place if any exposed PHP instance remains unpatched.

The detailed, continuously updated package-status guide by Mattias Geniar is useful when an installation does not match the standard cases above.

Since the maintenance window is already open

PHP2Shell is a good reason to stop postponing the whole upgrade chain. Update the CMS and its plugins, update PHP, and update the operating system. Take and verify a backup first, test compatibility, and have a rollback plan, but do not let preparation turn into another year of waiting.

A legacy backport can close today’s PHP2Shell hole. Moving to a supported OS and PHP release means somebody is also preparing a package for tomorrow’s hole. That is the less exciting upgrade benefit, and probably the most important one.