PHP Patches Two Critical Flaws on Wednesday. Prepare Today

What the PHP Security Team Announced

On October 20, the PHP security team posted an advance notice on php.net. A security release is scheduled for Wednesday, October 21, 2026, at 14:00 UTC, and it addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.

The notice asks every PHP user to prepare now, so the upgrade can go out as soon as the release is available. It also says the team may release earlier if details of either vulnerability become public, or if evidence of active exploitation appears. Full details, the affected versions and the fixed versions will be published together with the release.

That is the whole announcement. It names no CVE, no extension and no attack path, and it does not say whether either flaw allows code execution. Some reports circulating today describe a single remote code execution bug with a CVSS score of 10.0. The official notice says two vulnerabilities, rated 9.2, and nothing more, so that is what this piece works from.

When That Is Where You Are

The release time is fixed in UTC. Daylight saving time is still in effect in Europe and North America on October 21, so the local times below hold for that day.

For most of Europe that lands in the late afternoon, which is a reason to agree today who will be around to apply it, instead of finding out at five o'clock.

What We Know and What We Do Not

A score of 9.2 sits in the critical band of CVSS v4.0, which runs from 9.0 to 10.0. The security team rarely gives advance notice at all, and doing it for two issues at once tells you how seriously it takes them.

What is not known yet matters just as much. The notice does not say which part of PHP is affected, so nobody can say today whether a given site is exposed through a common feature or through an extension it never loads. It does not say whether the bugs need a particular configuration, and it does not list the versions involved. Anyone claiming those details before 14:00 UTC is guessing.

The practical reading is to assume every PHP installation you run is in scope until the advisories say otherwise. If the details later show that a flaw sits in an extension you do not use, you will have prepared for nothing more than an ordinary patch.

Why Advance Notice Cuts Both Ways

An advance notice gives defenders a head start, and the release takes it away again. Once the fixed versions are published, the changes in the source are public, and anyone can compare them with the previous release to work out what was broken. The hours after 14:00 UTC are when an unpatched server is easiest to find, so the value of the notice depends entirely on being ready to use it.

Which Branches Will Get a Fix

PHP publishes fixes only for branches it still supports. As of today those are the four PHP 8 branches below, which is why only PHP 8 can expect a patched release.

PHP 8.1, 8.0 and every 7.x release are past end of life. If either flaw reaches back that far, there will be no fix for those versions from php.net at all. Note too that 8.2 has a little over two months of security support left, so a server moving off an old branch this week should not stop at 8.2.

Find Every PHP You Run

Most teams know the PHP version of their main site and forget the rest. A server can run several versions side by side, the command-line PHP can differ from the one serving web requests, and containers carry their own. A short inventory today saves a scramble tomorrow.

On Debian and Ubuntu, each installed version has its own directory and its own FPM service.

php -v
ls /etc/php/
systemctl list-units --type=service 'php*-fpm*'

On Plesk, the panel lists every PHP handler it manages, and on cPanel the WHM API lists the installed EasyApache PHP versions.

plesk bin php_handler --list
whmapi1 php_get_installed_versions

For containers, look at what your images are built from and what is actually running.

grep -rn "FROM php:" --include="Dockerfile*" .
docker ps --format '{{.Image}}' | grep -i php

Put every result on one list, with the branch, where it runs and who owns it. Anything on 8.1 or older goes on a second list, because it needs a different plan.

Where Your PHP Comes From Decides When You Get the Fix

The source code lands on php.net at 14:00 UTC. Very few servers install PHP from source, so the fix reaches most of them through someone else's package, on that packager's schedule.

• Official Docker images (php:8.x) are rebuilt after the release and then reach you only when your own images are rebuilt on top of them.
• Debian and Ubuntu usually patch the version they shipped and keep its number. On those systems php -v can show an older-looking version that already carries the fix, so check the package changelog with apt changelog instead of the version string.
• Third-party repositories that follow upstream versions, such as the widely used Sury packages for Debian and Ubuntu, move to the new release numbers.
• Plesk and cPanel ship their own PHP builds and deliver them through their own update channels.

None of these is wrong, but each has its own delay. Knowing today which source each server uses tells you who to watch tomorrow, and which servers may still be waiting on a package hours after the announcement.

If You Skipped the September Release

The last PHP security release came out on September 24, as 8.2.34, 8.3.35, 8.4.26 and 8.5.11. It fixed a batch of issues, including unbounded recursion in the SOAP server rated high, a TLS hostname check that could fall back to the certificate's common name after a SAN mismatch, a heap overflow in wildcard certificate matching, and an IPv6 bypass of PHP-FPM's listen.allowed_clients.

A server that never applied that release has more to catch up on, but the work is the same single step. Moving to tomorrow's version brings in the September fixes as well.

A Plan for Wednesday Afternoon

1. At 14:00 UTC, read the advisories and note the affected component, versions and any configuration conditions. If a flaw sits in an extension you can disable safely, that is a stopgap for servers whose packages have not arrived yet.
2. Update in the order of exposure, starting with public sites that accept user input, then admin panels and internal tools.
3. Restart what runs PHP. PHP-FPM and Apache with mod_php keep running the old code until they are restarted, so confirm the service actually came back on the new build with systemctl status and a php -v from the same binary.
4. Rebuild container images from the updated base image without cached layers, and deploy them through your normal pipeline.
5. Check one real page on each site after the restart. A fixed PHP that took a site down is a different incident.

For Magento, WordPress and Laravel sites the order matters more than the method. A store that takes payments and a contact form on a marketing site do not carry the same risk, and the inventory from today is what lets you patch the first one first.

How to Confirm a Server Is Patched

A finished upgrade is a claim until the running process proves it. On Debian and Ubuntu, the package changelog normally names the fixed CVEs once they are published, and the FPM binary for each branch reports its own build. For containers, check the image itself instead of the tag you think you pulled.

apt changelog php8.3-fpm | head -20
php-fpm8.3 -v
docker run --rm php:8.3-fpm php -v

On packages that follow upstream numbering, the version string should match the new release listed on php.net. On distribution packages that keep their own numbering, the changelog entry is the evidence.

If You Host PHP for Others

Agencies and hosting providers have a second job today, which is telling customers. A short note that PHP will be updated on Wednesday evening, with a time window, prevents most of the questions that would otherwise arrive after a restart. Shared servers often run several PHP versions for different customers, and each handler needs the update, not only the default one. Customers still on an end-of-life branch are the hard case, since there may be nothing to install for them, and that is a conversation better started before the details are public.

Branches That Will Not Get a Fix

If the advisories confirm that 8.1 or older is affected, those servers have no patch coming. The only real fix is a move to a supported branch, ideally 8.4 or 8.5 given how little time 8.2 has left. That is an application change, not a package update, because frameworks and plugins have their own supported PHP versions. Start by checking which versions your framework supports, and give the move its own window instead of folding it into an emergency patch.

The same day brings security releases for Node.js too, as covered in Node.js security fixes landing on October 21. Keeping PHP current across shared, Plesk and cPanel servers is what our server management service does day to day.

Sources: php.net advance notice of the October 21 security release, PHP supported versions, php-src security advisories