Critical PHP Security Release (21 October 2026): What We Know and How to Upgrade

Status: last updated 21 October 2026, 08:00 UTC. The PHP security release has been announced but is not published yet. It is scheduled for today, 14:00 UTC. Official CVE IDs, affected versions and fixed versions are still pending. Everything marked "unconfirmed" below comes from leaks and third-party reporting, not from the PHP project. I will update this post once php.net publishes the release.

On 20 October 2026 the PHP security team announced on php.net an upcoming security release for Wednesday, 21 October 2026 at 14:00 UTC. It fixes two critical vulnerabilities, both rated CVSS v4.0 9.2. An out-of-band announcement like this is rare - the PHP project normally ships security fixes quietly with its regular releases. When it warns everybody a day in advance, it expects attackers to move fast.

This post sums up what is confirmed, what is only reported, and - most importantly - how to get your servers, containers and hosting accounts onto the fixed versions the same day.

Running PHP yourself and short on hands today? Email hello@dogan-ucar.de - I take on same-day patch work for this release.

Plan to patch every PHP installation on the day of the release, starting with internet-facing systems. If you still run PHP 8.1 or older, assume you will not get an official fix and plan to isolate or upgrade those hosts now.

What the PHP project has confirmed

The official notice is short. This is everything it says:

• A security release is scheduled for Wednesday, 21 October 2026, 14:00 UTC (16:00 CEST, 10:00 EDT).
• It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
• All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.
• The team may release earlier if details of either vulnerability become public or if active exploitation is seen in the wild.
• Full details, affected versions and fixed versions will be published with the release.

Security fixes from the PHP project go to supported branches only. At the time of writing these are PHP 8.2, 8.3, 8.4 and 8.5. PHP 8.6 is still a release candidate (RC3, with RC4 planned for 22 October) and must not be used in production. PHP 8.1 and everything older is end of life.

What is reported, but not confirmed

Details leaked on 20 October, before the planned disclosure. Several security vendors have since published what they know. Treat all of this as unconfirmed until the official advisory is out:

One unverified claim points at the multipart request parser and session upload-progress handling. Nobody has shown this, and I would not build a workaround on it. The only reliable fix is the patched PHP version.

Sansec expects mass scanning to start within minutes of the release, because the patch itself shows attackers where the bug is. That is why "we will patch next sprint" is the wrong plan here.

Am I affected? Find every PHP installation

Until the advisory says otherwise, assume every PHP installation is affected. The hard part is usually not the upgrade, but knowing where PHP actually runs. Check:

• Web servers (PHP-FPM, Apache with mod_php, php-cgi)
• Docker images and Kubernetes deployments - including old images that are still running
• CI runners and build images
• Queue workers, cron hosts and long-running processes (Symfony Messenger, Laravel Horizon, RoadRunner, FrankenPHP, Swoole)
• Shared hosting, managed WordPress, Plesk or cPanel servers
• Vendor appliances and internal tools that ship their own PHP

On each host, check the version that actually serves requests. The CLI and FPM versions can differ, especially on servers with several PHP versions installed side by side:

# CLI version
php -v

# FPM version (binary name depends on the distribution)
php-fpm8.4 -v        # Debian/Ubuntu
php-fpm -v           # RHEL, Alpine, official Docker images

# All installed PHP packages on Debian/Ubuntu
dpkg -l | grep -E '^ii\s+php'

# All installed PHP packages on RHEL/Alma/Rocky
rpm -qa | grep -i php

# Version inside a running container
docker exec <container> php -v

On the web side, a temporary phpinfo() page behind authentication shows the exact version FPM uses - delete it right after. In WordPress, the version is under Tools → Site Health → Info → Server. Also look at config.platform.php in your composer.json and at the FROM lines of your Dockerfiles: they tell you which branch you are on, but not which patch version runs.

How to upgrade, step by step

Prepare everything before 14:00 UTC: know your hosts, have access, have a maintenance window and a rollback plan. Then install the fixed version as soon as your package source has it. Note that distribution packages can lag a few hours behind php.net, and some distributions backport fixes into their own version numbers.

Debian and Ubuntu

Most servers that run current PHP versions use the packages by Ondřej Surý (packages.sury.org or the ppa:ondrej/php PPA), which usually follow php.net within hours. Distribution packages (for example php8.2 in Debian 12 or php8.3 in Ubuntu 24.04) get backported fixes from the security team instead, with a different version string.

sudo apt update

# See which version would be installed
apt policy php8.4-fpm

# Upgrade only the PHP packages of your branch
sudo apt install --only-upgrade 'php8.4*'

# Restart FPM so the new binary is actually used
sudo systemctl restart php8.4-fpm

# Check the changelog entry for the security fix
apt changelog php8.4-fpm | head -20

RHEL, AlmaLinux and Rocky Linux

With the Remi repository the commands look like this. RHEL's own AppStream modules receive backported fixes from Red Hat, so check the errata rather than the version number.

sudo dnf clean metadata
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
php -v

Docker and Kubernetes

Containers do not patch themselves. A running container keeps the vulnerable PHP until the image is rebuilt and redeployed. The official php images on Docker Hub are usually rebuilt shortly after a release.

# Pin to the fixed patch version once it is published, e.g.
# FROM php:8.4.27-fpm   (version unconfirmed until release)
# or keep a floating minor tag and force a fresh pull:
docker build --pull --no-cache -t my-app:php-security .

# Verify the version inside the new image
docker run --rm my-app:php-security php -v

Then redeploy every service that uses PHP - web, workers, cron jobs - and make sure no old pods or containers are left behind. In Kubernetes, kubectl rollout restart only helps if the image tag actually points to the new build.

Shared and managed hosting

On shared hosting you cannot patch PHP yourself, but you can make sure your provider does. A short email is enough:

Hello,

the PHP project releases fixes for two critical vulnerabilities
(CVSS 9.2) on 21 October 2026, 14:00 UTC.

1. When will the fixed PHP versions be deployed on my account/server?
2. Which PHP version does my account use, and is it still supported?
3. If it is end of life (8.1 or older): will you backport the fix,
   or do I need to switch to a supported version?

Thank you

If your account runs an old version, switch to PHP 8.4 or 8.5 in the hosting control panel - after testing it on a staging copy if you have one.

Windows

Download the new build from windows.php.net, matching your thread-safety and architecture (TS or NTS, x64), replace the installation, keep your php.ini, and restart IIS or Apache.

Restart everything and verify

Installing the package is only half the job. Every process that loaded the old binary keeps running it:

• Restart PHP-FPM, and Apache when you use mod_php.
• Restart queue workers and supervisors (messenger:consume, Horizon, Supervisor programs).
• Restart long-running application servers such as RoadRunner, FrankenPHP or Swoole.
• Verify the version where requests are served, not only on the CLI.
• Run your smoke tests: login, checkout, file uploads, background jobs.

Still on PHP 7.x, 8.0 or 8.1?

This is the uncomfortable part. If the reports are right, the vulnerable code goes back many years, but the PHP project only fixes supported branches. PHP 8.1 has been end of life since the end of 2025, and 8.0 and 7.x even longer. There will most likely be no official fix for them.

What you can do today:

• Reduce exposure: take the application off the public internet, put it behind a VPN, or restrict access with an IP allowlist.
• Use backports where they exist: Debian LTS/ELTS, Ubuntu Pro, RHEL and some commercial vendors maintain old PHP versions and may ship a backported fix. Check with your vendor.
• Prepare WAF rules once details are public - as an extra layer, not a replacement for the patch.
• Monitor closely for signs of compromise (see below).

And in the next weeks: upgrade to PHP 8.4 or 8.5. A jump from 7.4 or 8.0 to a current version is real work - removed functions, stricter type handling, dependency updates - but it is far more predictable than running an unpatched runtime with a known RCE. The legacy PHP migration checklist walks through the order of work, and my posts on PHP 8.4 and what can break when upgrading to PHP 8.6 cover the newer changes.

How to spot a compromise

No indicators of compromise have been published yet. Until they are, watch for the typical behaviour of a successful PHP remote code execution, as Huntress recommends:

• PHP worker processes (php-fpm, php-cgi, apache2, httpd) starting shells (sh, bash), interpreters (python, perl) or network tools (curl, wget, nc).
• Command lines containing /dev/tcp/, mkfifo or fsockopen.
• Reconnaissance commands like whoami, id or uname -a run by the web server user.
• New or modified .php files in the web root and upload directories.
• New cron jobs, systemd units, SSH keys or user accounts.

# PHP files changed in the last 2 days in the web root
find /var/www -name '*.php' -mtime -2 -ls

# Processes started by the web server user
ps -o pid,ppid,user,cmd -u www-data

If you suspect a compromise: isolate the host, keep the web server and PHP logs, and do not simply patch and move on - the attacker may already have left a webshell that survives the update.

Checklist for today

Before 14:00 UTC

• List every PHP installation, including containers, workers and hosting accounts.
• Record the PHP version and SAPI for each one.
• Make sure you have access and know who applies updates.
• Ask your hosting providers when they deploy the fix.
• Plan a maintenance window and a rollback for each system.
• Isolate or restrict hosts on PHP 8.1 and older.

At release

• Read the official advisory: affected versions, fixed versions, any workarounds.
• Patch internet-facing systems first.
• Rebuild and redeploy container images.
• Restart FPM, Apache, workers and application servers.
• Verify the running version on every host.

In the 24 hours after

• Watch logs and processes for the signs listed above.
• Patch the remaining internal systems, CI images and developer machines.
• Plan the upgrade of every end-of-life installation.

For a broader look at hardening PHP in production, see my summary of the 2025 PHP core security audit and the post on mail injection in PHP.

Sources

• php.net: Upcoming Critical PHP Security Release (20 October 2026)
• Help Net Security: A critical PHP security release is coming today
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Sansec: Critical PHP RCE CVE-2026-109618 and CVE-2026-109619
• Mallory: PHP remote code execution, rapid response
• Phoenix Security: PHP core RCE CVE-2026-109618 and CVE-2026-109619