Patching PHP2Shell: platform by platform

Two traps before you start

• The version number may not move. Ubuntu, AlmaLinux, CloudLinux and others backport the fix into the version they already ship, and Red Hat does the same for its PHP 7.4 and 8.0 packages. Ubuntu 24.04's fixed package still reports PHP 8.3.6. Judge a distribution package by its package version against the vendor's advisory, not by php -v; AlmaLinux says so in as many words.
• The command line is not the web server. Several PHP versions are often installed side by side, and the one on your PATH may not be the one PHP-FPM or Apache uses. Check each PHP-FPM version, the Apache module, or a temporary phpinfo() page that shows the "Server API" line, and delete it afterwards.

# which PHP builds are installed, and at what package version
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'     # Debian, Ubuntu
rpm -q php-common php-fpm                       # RHEL, Alma, Rocky, Fedora
rpm -q php8.4-common                            # RHEL 10 family, PHP 8.4
# what the web server side reports
ls /etc/php                                     # Debian, Ubuntu: one php-fpmX.Y per version
php-fpm8.3 -v
apache2ctl -M 2>/dev/null | grep -i php         # Debian, Ubuntu with mod_php
httpd -M 2>/dev/null | grep -E 'mpm_|php'       # RHEL family

Linux distributions

# Debian, Ubuntu
sudo apt update && sudo apt upgrade
# RHEL, AlmaLinux, Rocky, Oracle, CentOS Stream, Fedora
sudo dnf upgrade --refresh 'php*'
# Amazon Linux 2023: a plain upgrade stays on the release the instance is locked to
sudo dnf upgrade --releasever=latest 'php*'
# Amazon Linux 2, php8.2 extra
sudo yum update --advisory ALAS2PHP8.2-2026-015
# SUSE, openSUSE
sudo zypper refresh && sudo zypper patch

Third-party repositories

• Ondřej Surý's packages (the ppa:ondrej/php PPA and packages.sury.org, used by many Debian and Ubuntu servers and by Laravel Forge): fixed builds for every branch from PHP 5.6 to 8.5 were published on 21 October, with the older branches carrying a backport of the fix. By the afternoon of 22 October the PPA had them on every architecture. packages.sury.org still served the old PHP 8.3, 8.4 and 8.5 builds on arm64, and its maintainer expected those to take about two days. Check the package version on each architecture. The 5.6 to 7.1 builds also lack the multipart body-parts limit that the upstream 7.4 backport includes; the maintainer has confirmed this and plans an update.
• Remi's repository (rpms.remirepo.net, common on RHEL-family systems): the php.net advisory said it would have no updates on release day, but the repository's maintainer reported the builds already published at 14:21 UTC, and its metadata showed fixed builds for EL 8, 9 and 10 and Fedora 43 and 44, including backports for 7.4, 8.0 and 8.1. Users reported mirrors lagging behind. Enterprise Linux 7 will not be updated.

# Remi: confirm your mirror actually has the new build before you rely on it
sudo dnf clean all && sudo dnf upgrade --refresh 'php*'
rpm -q --changelog php-fpm | head

Containers

A container image does not update itself, and restarting a container does not change its image. The official Docker php images were rebuilt on 21 October with fixed tags such as 8.4.27-fpm and 8.3.36-apache, including Alpine variants, which compile PHP from source rather than using Alpine's packages.

• Pin the full version in your Dockerfile, for example FROM php:8.4.27-fpm, rather than a floating tag.
• Rebuild with docker build --pull so the new base image is fetched, then recreate the containers.
• At 13:30 UTC on 22 October the fixed tags still had no riscv64 build, so on riscv64 the floating tags such as php:8.4 still pointed at the old, vulnerable images. The ppc64le builds missing on 21 October have since been published.
• PHP 8.1 and older official images were not rebuilt.
• FrankenPHP embeds PHP, so operating system packages do not fix it. Version 1.13.2 ships the fixed PHP releases; replace the binary or image and restart the process.
• Verify inside the running container: docker exec <container> php-fpm -v.

Control panels

Managed hosting and cloud platforms

If someone else runs PHP for you, the update is theirs to install, and yours to confirm. Ask for the version and the date, in writing.

Restart, so the new binary is the one running

Every source repeats this, because it is the step people skip: the PHP project says to restart every worker. A process that started before the update keeps the old code in memory.

# any process still mapped to a deleted (replaced) PHP binary or library?
sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps 2>/dev/null
# when did each PHP process start?
ps -eo pid,lstart,cmd | grep -i '[p]hp'

Known issues after upgrading

The fixed releases change how PHP handles running out of memory, and a handful of regressions were reported in the php-src issue tracker within a day. None is a reason to stay on a vulnerable version; all are reasons to test before and watch after.

Then verify, from the outside in

• Compare the installed package version with your vendor's advisory for CVE-2026-109618 and CVE-2026-109619.
• Check the version the web server reports, through PHP-FPM, the Apache module or a temporary phpinfo() page.
• Confirm no PHP process started before the update is still running.
• Record what you did, on which hosts, and when. If a supervisor or customer asks, that record is your answer.