FROM php:8.1-apache. I found that line twice last week, in two repositories nobody on the current team had touched since 2023, and both images were cheerfully answering requests on 22 October, one day after the PHP project published fixes for CVE-2026-109618 and CVE-2026-109619. Apache with mod_php, of all setups, the one the PHP team flagged as the most dangerous place to be. The people who own those repos got lucky in a way I doubt we will see again. Core did not stop at 8.2.35, 8.3.36, 8.4.27 and 8.5.12. It also put out minimal source patches for 7.4, 8.0 and 8.1, three branches that had already left the normal support cycle.

That deserves real thanks, and it deserves an honest reading too. Somebody on php-src spent emergency hours inside code they had formally waved goodbye to, so that teams who never scheduled an upgrade would have a way out. If your plan for the next critical engine bug quietly assumes core will do that again, you are planning around a favor. For most of us the lesson of PHP2Shell sits in the upgrade calendar, weeks before any incident channel opens.

Look at what a source patch actually hands you. A diff. To turn it into something running in production you need a working build of PHP itself, every extension you compile against it, and someone who still knows which configure flags the original image used. I have watched a team lose a full afternoon because pdo_pgsql would not link against their hand-built 8.0. And the teams that keep a healthy PHP build pipeline around are, almost by definition, rarely the ones still sitting on 8.1.

The strongest pushback deserves a fair hearing, and it is a good one. An old version string does not make a server negligent. Distributions and LTS vendors backport security fixes into their packages without bumping to the upstream number, and the PHP announcement itself pointed people to those vendors. A box reporting something that looks ancient can be fully covered by its vendor, and I would never tell a shop running a supported enterprise distro to panic over the output of php -v.

Where that argument stops working is the difference between a contract and a habit. A backport means a named vendor, a published advisory, and a package reference you can paste into a ticket. A base image pinned in 2023 and never rebuilt has none of those. It just looks stable because nothing has broken yet, which is exactly how it looked on 20 October.

Speed is what the stale image really costs you. Cloudflare reported attack traffic, plus attackers reworking their payloads to slip past its rules, and still told customers to patch PHP rather than lean on the WAF. ENISA went a step further and suggested pulling public facing applications off the network if fixes could not be applied, and warned that PHP hides inside products whose users have no idea it is there. Isolation is the move for when you cannot ship. On a supported branch with routine minor bumps, this whole thing was a dull Tuesday: change 8.3.35 to 8.3.36, let CI run, roll it out, go to lunch. On 8.1 it was a build project with a ticking clock.

So my case is boring on purpose. Let a bot open the patch release PR every time core tags one, and merge it the same week unless tests object. Keep a written rule for how far behind the oldest supported branch you are allowed to fall, and treat crossing it as a bug with an owner. Do the painful major jumps on a quiet sprint you chose, because the alternative is doing them under a CVE number with customers watching. None of that is clever. It just turns the next PHP2Shell from an emergency into a changelog line, and it stops us from spending the goodwill of the people who maintain the runtime we all depend on.

Here is what I would really like to hear from you in the comments: how far behind the newest supported PHP branch is your oldest production workload right now, and, being honest, how long would it take you to get a patched build of it serving traffic if the next advisory dropped tomorrow morning?