PHP pre-announced two critical remote code execution bugs last week, rated 9.2 out of 10, and brought the release forward by a day after details leaked. The fix shipped at 14:00 UTC on 21 October, which is 3am on the 22nd in New Zealand. By 06:27 NZDT every server we run for clients had it.
The speed was not the interesting part. The PHP versions were. This is what happened, in order, and why nearly half the sites on our main server were patched on a PHP version that PHP itself stopped supporting at the end of 2025.
What Was Announced
On 20 October php.net announced a security release for two critical bugs, CVE-2026-109618 and CVE-2026-109619, since nicknamed PHP2Shell. The release was first set for 22 October and was moved to 21 October 14:00 UTC after details leaked. One bug corrupts memory when PHP runs out of it, the other leaves stale state behind between requests. Both can lead to code execution on the server.
Before the release, the reported way in was PHP’s upload progress handling. That is a PHP feature that tracks file uploads in the session. It is on by default, and WordPress does not use it.
Before the Fix Existed
We learned of the announcement at 15:49 NZDT on 21 October. By 18:30 NZDT upload progress handling was off on our main server, and a request to a live PHP pool for each version (8.1, 8.2, 8.3 and 8.4) confirmed the new setting. By 18:35 NZDT it was off on every server and recorded in our server configuration, so a rebuild would not turn it back on.
Every change that evening was a graceful reload, not a restart, so running requests finished normally. The mitigation was in place eight and a half hours before the fix was published. It does not replace the patch. It narrows the gap while there is nothing to install yet.
Release Night
PHP released fixed versions at 03:00 NZDT: 8.2.35, 8.3.36 and 8.4.27, plus backport branches for older versions. We take our PHP packages from Ondřej Surý’s repository for Ubuntu, which builds every supported PHP version and backports security fixes to the ones PHP no longer supports. The fixed builds were stamped between 14:28 and 14:35 UTC, half an hour after the release, with 8.1 first.
A build existing and a build being installable are two different things. When we started at 05:29 NZDT, the repository’s download mirror was returning 503 errors, and once it recovered it still had not published the new files. The build service had them. We downloaded the packages directly from it and checked every file against the checksums the build published before installing anything.
The first server was patched and verified at 05:56 NZDT. The mirror offered the same version as an update two minutes later. The main server followed at 06:11 NZDT and the last one at 06:27 NZDT, 3 hours 27 minutes after the release and 58 minutes after we started.
Each PHP version was restarted on its own, and sites were checked before moving to the next version. Afterwards we confirmed that no PHP process was still running the old binary, which is the usual way a patch is installed but not actually in use.
Why 8.1 Still Gets Patched
48% of the live sites on our main server run PHP 8.1, not counting staging copies. PHP 8.1 reached end of life on 31 December 2025, so php.net did not release a fixed 8.1. The backported 8.1 we run did get one, 28 minutes after the release.
The alternative was to move all of those sites to a newer PHP that night. A PHP version change is the kind of update that breaks an old plugin or theme, and doing it on a deadline at 4am turns a security fix into an outage. A backport splits the two jobs. The security fix goes in the same night, and the version upgrade waits until each site has been tested on staging.
PHP 8.3 leaves security support at the end of 2027. We expect to run a backported 8.3 in the same way after that.
Backports are a more efficient way to stay on fewer PHP versions for longer. Every version we run is another set of packages to patch on a night like this one, so moving sites in a few larger steps costs less than following every PHP release. There is still a date. Backports for a version end too, and the sites on it have to move before then.
The Timeline
| Event | UTC | NZDT |
|---|---|---|
| We learn of the pre-announcement | 21 Oct 02:49 | 21 Oct 15:49 |
| Upload progress off on the main server, verified | 21 Oct 05:31 | 21 Oct 18:31 |
| Upload progress off on every server | 21 Oct 05:35 | 21 Oct 18:35 |
| PHP releases the fix | 21 Oct 14:00 | 22 Oct 03:00 |
| Backported builds created (8.1 first, 8.4 last) | 14:28 to 14:35 | 03:28 to 03:35 |
| Patching starts, mirror returning 503 | 16:29 | 05:29 |
| First server patched from the build service | 16:56 | 05:56 |
| Fixed version offered by the mirror | 16:58 | 05:58 |
| Main server patched | 17:11 | 06:11 |
| Every server patched | 17:27 | 06:27 |
Clients did not have to do anything.
What to Check on Your Own Server
If you run your own server, check three things. First, which PHP version each site runs. Second, which repository the PHP packages come from, and whether that repository still backports fixes to that version. Third, whether PHP-FPM was restarted after the update, because a patched package on disk does not help while the old process is still serving requests.
If the answer is PHP 8.1 from a source that stopped backporting, last week’s fix did not reach you. If you are not sure, we are happy to take a look.
