FROM php:8.1-apache. Diese Zeile habe ich letzte Woche zweimal gefunden, in zwei Repositories, die seit 2023 niemand aus dem aktuellen Team angefasst hatte, und beide Images haben am 22. Oktober fröhlich Requests beantwortet, einen Tag nachdem das PHP-Projekt Fixes für CVE-2026-109618 und CVE-2026-109619 veröffentlicht hatte. Ausgerechnet Apache mit mod_php, also genau das Setup, das das PHP-Team als den gefährlichsten Ort überhaupt markiert hatte. Wem diese Repos gehören, der hatte Glück, und zwar auf eine Art, die wir so wohl kein zweites Mal erleben. Core hat nicht bei 8.2.35, 8.3.36, 8.4.27 und 8.5.12 aufgehört. Es gab zusätzlich minimale Quellcode-Patches für 7.4, 8.0 und 8.1, drei Branches, die den regulären Support-Zyklus schon verlassen hatten.

Dafür gebührt echter Dank, und zugleich eine ehrliche Lesart. Jemand bei php-src hat Notfallstunden in Code gesteckt, von dem man sich offiziell verabschiedet hatte, damit Teams, die nie ein Upgrade eingeplant haben, einen Ausweg bekommen. Wenn dein Plan für den nächsten kritischen Engine-Bug stillschweigend davon ausgeht, dass Core das wieder tut, dann planst du mit einem Gefallen. Für die meisten von uns steckt die Lehre aus PHP2Shell im Upgrade-Kalender, Wochen bevor sich irgendein Incident-Channel öffnet.

Schau dir an, was dir ein Source-Patch tatsächlich in die Hand gibt: einen Diff. Um daraus etwas zu machen, das in Produktion läuft, brauchst du einen funktionierenden Build von PHP selbst, jede Extension, die du dagegen kompilierst, und jemanden, der noch weiß, mit welchen configure-Flags das ursprüngliche Image gebaut wurde. Ich habe erlebt, wie ein Team einen ganzen Nachmittag verloren hat, weil sich pdo_pgsql nicht gegen sein selbstgebautes 8.0 linken ließ. Und die Teams, die eine gesunde PHP-Build-Pipeline pflegen, sind praktisch per Definition selten die, die noch auf 8.1 sitzen.

Der stärkste Einwand verdient ein faires Gehör, denn er ist gut. Ein alter Versionsstring macht einen Server nicht fahrlässig. Distributionen und LTS-Anbieter backporten Sicherheitsfixes in ihre Pakete, ohne auf die Upstream-Nummer zu springen, und die PHP-Ankündigung selbst hat auf genau diese Anbieter verwiesen. Eine Kiste, die etwas uralt Aussehendes meldet, kann von ihrem Anbieter vollständig abgedeckt sein, und ich würde nie einem Laden mit einer unterstützten Enterprise-Distro raten, wegen der Ausgabe von php -v in Panik zu geraten.

Das Argument trägt aber nur bis zum Unterschied zwischen einem Vertrag und einer Gewohnheit. Ein Backport bedeutet einen namentlich bekannten Anbieter, ein veröffentlichtes Advisory und eine Paketreferenz, die du in ein Ticket kopieren kannst. Ein Base-Image, das 2023 gepinnt und nie neu gebaut wurde, hat nichts davon. Es wirkt nur stabil, weil bisher nichts kaputtgegangen ist, und genau so wirkte es auch am 20. Oktober.

Was dich das veraltete Image wirklich kostet, ist Geschwindigkeit. Cloudflare hat Angriffstraffic gemeldet, dazu Angreifer, die ihre Payloads umbauen, um an den Regeln vorbeizukommen, und den Kunden trotzdem geraten, PHP zu patchen, statt sich auf die WAF zu verlassen. ENISA ist noch einen Schritt weiter gegangen: Öffentlich erreichbare Anwendungen sollten vom Netz, falls sich die Fixes nicht einspielen lassen, und PHP stecke in Produkten, deren Nutzer gar nicht wissen, dass es da ist. Isolation ist der Zug für den Fall, dass du nicht ausliefern kannst. Auf einem unterstützten Branch mit routinemäßigen Minor-Bumps war das Ganze ein langweiliger Dienstag: 8.3.35 auf 8.3.36 ändern, CI laufen lassen, ausrollen, Mittagessen. Auf 8.1 war es ein Build-Projekt mit tickender Uhr.

Mein Plädoyer ist also mit Absicht langweilig. Lass einen Bot den PR für jedes Patch-Release öffnen, sobald Core eins taggt, und merge ihn in derselben Woche, solange die Tests nicht widersprechen. Halte schriftlich fest, wie weit du hinter den ältesten unterstützten Branch zurückfallen darfst, und behandle jede Überschreitung als Bug mit einem Owner. Mach die schmerzhaften Major-Sprünge in einem ruhigen Sprint, den du selbst gewählt hast, denn die Alternative ist, sie unter einer CVE-Nummer zu erledigen, während die Kundschaft zuschaut. Nichts davon ist clever. Es macht aus dem nächsten PHP2Shell nur eine Zeile im Changelog statt eines Notfalls, und es sorgt dafür, dass wir nicht das Wohlwollen der Leute verbrauchen, die die Runtime pflegen, von der wir alle abhängen.

Was ich wirklich gern von dir in den Kommentaren lesen würde: Wie weit liegt dein ältester Produktiv-Workload gerade hinter dem neuesten unterstützten PHP-Branch, und, ganz ehrlich, wie lange würdest du brauchen, um einen gepatchten Build davon live zu bekommen, wenn das nächste Advisory morgen früh erscheint?