PHP ships two 9.2 fixes today at 14:00 UTC: what to do before then

On 20 October 2026 at 20:32 UTC, php.net posted a notice titled Upcoming Critical PHP Security Release. It says three things: the release is scheduled for Wednesday, 21 October 2026 at 14:00 UTC; it addresses two vulnerabilities, both rated CVSS v4.0 9.2; and the affected version ranges plus fixed versions will be published together with the release.

As I write this it is 10:14 UTC on the 21st — under four hours to go.

What the notice says, and what it deliberately does not

Five short paragraphs, and the information content is thin on purpose:

• it is an advance notice, not a disclosure;
• the time is 21 October, 14:00 UTC;
• two vulnerabilities, both 9.2;
• “we reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild”;
• “full details, affected versions, and the fixed versions will be published with the release.”

So: vulnerability class, trigger path, affected functions — nothing. Anyone claiming to know “where it is” right now is guessing. Two 9.2s in one release is also unusual; normally a security release carries one genuinely severe issue.

About 17 hours between notice and release — enough time to prepare, not to patch.

First: know which version you actually run

Before fixing anything, establish the facts:

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'

In containers, watch the tag: php:8.4-fpm floats with the official image, php:8.4.26-fpm does not. The first waits for an image rebuild, the second needs a tag bump — know which one you are, before the release lands.

Also confirm the SAPI: php-fpm, mod_php and php-cgi upgrade differently, and the CLI version may not match the FPM one (php -v only reports the CLI build).

Second: turn “we can roll back” into something you verified today

The biggest risk on release day is not the vulnerability, it is the upgrade. If that PHP process serves an application nobody has touched in five years, then after 14:00 you have two options: keep running with the bug, or upgrade in an environment with no way back.

Settle these now:

• whether your database migrations depend on the PHP minor version (they usually do not, but extensions do);
• whether you can switch back to a snapshot or previous image within ten minutes;
• whether key extensions (opcache, redis, imagick, swoole) already have builds for the new version — these are where upgrades stall.

Third: watch version numbers, not announcements

Going by PHP’s usual cadence, expect patched builds on four branches. The current baseline is the 24 September security batch:

Branch	Latest now	Active support until	Security support until
8.2	8.2.34	ended 2024-12-31	2026-12-31
8.3	8.3.35	ended 2025-12-31	2027-12-31
8.4	8.4.26	2026-12-31	2028-12-31
8.5	8.5.11	2027-12-31	2029-12-31

Two things stand out. 8.2 security support ends in about two months (2026-12-31) — if you are still there, this patch buys you a short runway, not a permanent one. And 8.4 active support also ends on 2026-12-31; after that it takes security fixes only.

Also: 8.6.0 is at RC3 (released 8 October). Release candidates do not get this security fix, so do not move production to an RC “to get it over with”.

What to check after 14:00

In this order:

1. read the affected version range and compare it to yours — plenty of “critical” issues hit one branch only;
2. read the trigger conditions (authentication required? specific extension or config?). A 9.2 does not mean your site is exploitable, it means that when the conditions hold, the outcome is severe;
3. upgrade, then smoke-test four paths: login, payment, upload, scheduled jobs. Those cover most “it broke after the upgrade” cases.

The short version

The value of the notice is not “another vulnerability”, it is the timetable. What has to happen today is small: know your version, verify you can roll back, automate watching the version number. The vulnerability itself can wait for the 14:00 announcement.