Updating PHP fast: distro packages, Sury, Remi and Docker

Updated November 2026

To patch PHP, find out which PHP binary actually serves your site, update it from the same source it was installed from, and restart PHP-FPM or Apache so the old code leaves memory. As of November 3, 2026, the safe upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a distro package that carries the same fixes.

• 8.5.12Fixed release for PHP 8.5
• 8.4.27Fixed release for PHP 8.4
• 8.3.36Fixed release for PHP 8.3
• 8.2.35Fixed release for PHP 8.2

Supported PHP branches

The PHP project supports each branch for two years of active support (bug and security fixes), then about two more years of security fixes only.

PHP 8.1 and older get no updates from the PHP project. PHP 8.2 reaches end of life in under two months, so plan its upgrade now. PHP 8.6 is still a release candidate and is not for production.

The October 2026 RCE fixes

On October 21, 2026 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two flaws that can allow unauthenticated remote code execution: CVE-2026-109618 (memory corruption after out-of-memory errors) and CVE-2026-109619 (stale internal state reused by a later request). The advisory covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php as the highest risk. It states there are no complete mitigations, so updating is the only safe choice.

Find which PHP serves the site

The php command on your shell is the CLI build. Your website may run a different version through PHP-FPM, mod_php or a container, so check each one.

php -v                                   # CLI version
ls /usr/sbin/php-fpm*                    # installed FPM binaries
php-fpm8.4 -v                            # Debian/Ubuntu: name includes the branch
php-fpm -v                               # RHEL, Fedora, Remi
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd|[f]rankenphp'
grep -R fastcgi_pass /etc/nginx/         # which FPM socket nginx uses
sudo apache2ctl -M | grep -i php         # Debian/Ubuntu: mod_php loaded?
sudo httpd -M | grep -i php              # RHEL/Fedora: mod_php loaded?

A line such as php-fpm: master process (/etc/php/8.4/fpm/php-fpm.conf) tells you the branch and config in use. The lstart column shows when each process started; you need that again after the update. For containers, run docker exec <container> php -v.

Debian and Ubuntu packages

Distro packages keep their original version number and add backported fixes, so php -v on Ubuntu 24.04 still says 8.3.6. Compare the package version, not the PHP version.

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade $(dpkg-query -W -f='${binary:Package}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null)
dpkg -l 'php8.4*' | grep ^ii
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.4-common/changelog.Debian.gz

Replace 8.4 with your branch. Ubuntu 20.04 and older receive these fixes only through Ubuntu Pro.

Sury repository (deb.sury.org)

The Sury repository (packages.sury.org for Debian, ppa:ondrej/php for Ubuntu) ships several PHP branches side by side under the same package names as Debian. Its Debian trixie packages were rebuilt on October 21, 2026 to 8.2.35, 8.3.36, 8.4.27 and 8.5.12, so php -v shows the upstream number.

apt policy php8.4-fpm        # confirm the candidate comes from packages.sury.org
sudo apt update && sudo apt upgrade

If you installed several branches, upgrade and restart each FPM service, not only the default one.

RHEL, Fedora and Remi

Red Hat fixed both CVEs on October 21, 2026, covering php and php8.4 on RHEL 10, php plus the php:8.2 and php:8.3 streams on RHEL 9, and the php:8.2 and php:7.4 streams on RHEL 8. Red Hat still listed the RHEL 9 php:8.4 stream as affected on November 3, so check its CVE page if you use it. Update within the stream you already use:

dnf module list php                       # RHEL 8/9: enabled stream is marked [e]
sudo dnf upgrade --refresh 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Remi's repository builds upstream versions as module streams on EL 8, 9 and 10. To move to another branch, the Remi wizard gives:

sudo dnf module switch-to php:remi-8.4    # upgrades or downgrades installed PHP
php --version

Alpine Linux

Alpine packages carry the upstream version: php84 8.4.27-r0 and php83 8.3.36-r0 are in Alpine 3.21 to 3.24, php85 8.5.12-r0 in 3.23 and 3.24. As root:

apk -U upgrade
php84 -v
rc-service php-fpm84 restart      # restarts the service

Official php Docker images

The official php images compile PHP from source, so apt-get upgrade inside the container does not update PHP. Pull the new base image and rebuild. Tags such as 8.4.27-fpm and 8.4-fpm-trixie were refreshed on October 31, 2026. If your Dockerfile pins an older patch tag such as 8.4.26-fpm, change it first.

docker build --pull -t myapp:latest .
docker compose build --pull && docker compose up -d     # recreates containers
docker compose exec app php -v

Restart and verify

Old PHP code stays in memory until every worker is replaced. Restart, even if the package scripts already did it:

sudo systemctl restart php8.4-fpm     # Debian/Ubuntu (restarts service)
sudo systemctl restart php-fpm        # RHEL, Fedora, Remi
sudo systemctl restart apache2        # mod_php on Debian/Ubuntu
sudo systemctl restart httpd          # mod_php on RHEL
sudo needrestart -r l                 # Debian/Ubuntu: list stale services
sudo dnf needs-restarting -s          # RHEL/Fedora

Run the ps command from above again: every PHP and Apache process should have a start time after the update. A full restart also empties OPcache, which lives in the FPM or Apache shared memory. Check its settings with php-fpm8.4 -i | grep -E '^opcache\.(enable|validate_timestamps|file_cache) '. If opcache.file_cache points to a directory, you can empty it while the service is stopped. See Restarts and reboots for more.

If you cannot update today

The PHP advisory lists mitigations that reduce exposure but do not make a server safe. Set them where requests cannot override them, for example in the FPM pool:

; /etc/php/8.4/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = off

• Do not use ini_set() or .user.ini for these settings, and restart every worker afterwards.
• With memory_limit = -1, add a container or cgroup memory limit instead. Do not use RLIMIT_AS or RLIMIT_DATA.
• Limit request size at the web server or proxy too, for example client_max_body_size 8m; in nginx.

End-of-life PHP

For PHP 8.1 and older, use a distro or vendor that still backports fixes (the Red Hat and Ubuntu Pro packages above, or a commercial PHP LTS vendor), or upgrade to 8.4 or 8.5. The PHP security team also published minimal source backports for 7.4, 8.0 and 8.1 for this incident. See Is my OS supported?.

Sources

• Supported Versions, PHP
• Security advisory: critical remote code execution vulnerabilities (Oct 21, 2026), PHP
• Informational advisory: session upload progress (Oct 23, 2026), PHP
• Known Exploited Vulnerabilities Catalog, CISA
• CVE-2026-109618, Debian Security Tracker
• CVE-2026-109618, Ubuntu
• CVE-2026-109618, Red Hat Customer Portal
• PHP repositories for Debian and Ubuntu, deb.sury.org
• Debian repository setup, packages.sury.org
• Configuration wizard, Remi's RPM repository
• php84 package, Alpine Linux
• php official image, Docker Hub
• FPM configuration, PHP Manual