Zweimal CVSS 9.2, und das Erste, was die Hälfte von uns am 21. Oktober getippt hat, war php -v. Ich auch, in einem Terminal auf einer Maschine, von der ich ziemlich sicher war, dass sie wichtig ist, und ich bekam eine beruhigende Zahl zurück, die mir so gut wie nichts sagte. Der Befehl meldet die CLI-Binary, die in deinem PATH liegt. Über den FPM-Pool hinter nginx sagt er nichts, genauso wenig über das Container-Image, das jemand vor drei Wochen gebaut hat, oder über den Queue-Worker, den Supervisor an einem Dienstag im August gestartet hat und seitdem am Leben hält.

Das Upgrade auf das gefixte Release ist diese Woche der billige Teil. Teuer wird es, weil die meisten Teams, mit denen ich spreche, die vollständige Liste der PHP-Prozesse, die in ihrem Namen Netzwerk-Traffic beantworten, weder aus dem Kopf noch aus einer Datei im Repo hervorholen können. Ohne diese Liste ist der Patch bloß eine Hoffnung. Du hast die Maschinen aktualisiert, an die du dich erinnert hast, und der Angreifer kümmert sich um die, die du vergessen hast.

Kurz die Fakten, weil sie erklären, warum das hier unterhalb deines Frameworks ansetzt. CVE-2026-109618 steckt in der Art, wie die Engine Requests behandelt, die ihr Speicherlimit sprengen, und CVE-2026-109619 ist ein Use-after-free, den ein Fatal Error für alles vorbereiten kann, was danach läuft. Beides sind Laufzeit-Bugs, deine Laravel-Middleware und deine sorgfältig geschriebenen FormRequest-Klassen stehen also im falschen Raum. Laut PHP-Team gibt es auch keine vollständigen Workarounds, du findest also kein ini-Flag, das du umlegen kannst, während du auf ein Wartungsfenster wartest. Die gefixten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35, und mehr steht nicht auf der Karte.

Am meisten Sorgen macht mir die Lebensdauer der Prozesse. Ein Paketmanager kann sein Upgrade sauber abschließen, während die alte Engine weiter im Speicher läuft, weil niemand dem FPM-Master gesagt hat, dass er neu laden soll. php artisan queue:work unter Supervisor, Horizon, Octane-Worker: Die sind alle darauf ausgelegt, wochenlang durchzulaufen, und das ist eine gute Eigenschaft, bis zu dem Moment, in dem genau der geladene Code verschwinden muss. Unsere Freunde aus der Go-Welt haben hier wenigstens einen kleinen Vorteil, auf den sie sich etwas einbilden dürfen: Wenn sie ein statisches Binary neu deployen, läuft genau das, was sie gebaut haben. Wir bekommen um 14:02 eine Erfolgsmeldung von apt und um 14:03 einen Worker, der seit 41 Tagen lebt und immer noch die alte Runtime ausliefert.

Der stärkste Einwand, den ich diese Woche gehört habe, ist berechtigt. Die meisten von uns setzen auf eine Distribution, eine Managed-Plattform oder ein Provisioning-Tool, gerade damit niemand im Team Runtimes babysitten muss, und diese Anbieter haben schnell gefixte Pakete ausgeliefert. Mehr noch: Distributionen backporten Sicherheitsfixes oft in eine ältere Versionsnummer, sodass eine Debian- oder Ubuntu-Maschine sicher sein kann, obwohl php -v etwas ausgibt, das veraltet aussieht. Einverstanden, aber das gilt in beide Richtungen. Wenn dich der Versionsstring in die beruhigende Richtung täuschen kann, dann auch in die gefährliche, und klären kann das nur eine Prüfung aus dem Prozess heraus, der die Requests bedient, und zwar nach seinem Neustart.

Was ich diese Woche tatsächlich bauen würde, ist langweilig und klein. Gib jeder App einen rein internen Health-Endpoint, der PHP_VERSION und die Startzeit des Prozesses aus FPM heraus meldet, nicht aus einer Shell, und lass dein Monitoring alles markieren, was älter als der Fix ist. Sorg dafür, dass die CI Base-Images unterhalb des gepatchten Releases für deinen Branch ablehnt. Führ pro Team eine einzige Datei mit jedem Host, jedem Image und jedem Worker, auf dem PHP läuft, und behandle sie wie Code. Das zahlt sich vor Neujahr gleich zweimal aus: PHP 8.2 erreicht am 31. Dezember 2026 das End of Life, und genau diese Datei sagt dir vom ersten Tag an, wer noch umziehen muss.

Nichts davon ersetzt die Suche nach Ärger. Seit dem Release sind sechs Tage vergangen, die Lücken sind ohne Login erreichbar, und ein sauberes Upgrade beweist nichts darüber, was vorher passiert ist. Durchsuch die FPM-Logs nach gehäuften Abstürzen, prüf, ob es Dateien und Admin-Accounts gibt, die du nicht angelegt hast, und rotier Zugangsdaten, wenn dir irgendetwas komisch vorkommt. Das ist ganz normale Incident-Hygiene, und sie wird viel einfacher, wenn du schon weißt, welche Maschinen du dir ansehen musst.

Das würde ich wirklich gern von dir unter diesem Text lesen: Könntest du jetzt sofort, ohne ein Terminal zu öffnen, sagen, welche PHP-Version den letzten Request deiner Produktiv-App bedient hat, und wie du das beweisen würdest? Prüfst du aus dem Request heraus, oder vertraust du darauf, dass die Pipeline getan hat, was sie behauptet? Und wenn du langlebige Worker betreibst, startest du sie bei jedem Runtime-Patch neu oder nur, wenn jemand daran denkt?