Mittwoch, 21. Oktober 2026, 14:00 UTC. Dieser Zeitstempel stand tagelang in meinem Kalender, bevor irgendetwas ausgeliefert wurde, und genau das ist das Seltsamste daran, wie PHP mit CVE-2026-109618 und CVE-2026-109619 umgegangen ist: Wir kannten die Uhrzeit des Fixes, bevor wir wussten, was kaputt war. Zwei Bugs, jeweils mit 9.2 nach CVSS v4.0 bewertet, ein CERT-EU-Advisory mit der Nummer 2026-018, das mögliche Remote Code Execution erwähnt, und ein Hinweis auf php.net, der sinngemäß sagte: Details kommen mit dem Release. Manche haben das als Geheimniskrämerei gelesen. Ich habe darin eine kostenlose Feuerwehrübung für jedes Team gesehen, und ich vermute, die meisten von uns haben sie damit verbracht, die Ankündigungsseite neu zu laden.

So wie ich das sehe, ist der schwierige Teil eines kritischen Runtime-Fixes mechanisch, und er steckt in deiner Pipeline. Den Bug zu verstehen kommt erst danach. Mit dem Advisory-Text kannst du nichts anfangen, solange es ihn nicht gibt, aber du kannst an einem ruhigen Dienstag herausfinden, ob das Anheben des PHP-Patchlevels in Produktion ein Zehn-Minuten-Job ist oder ein zweitägiges Archäologieprojekt. Wenn du für einen Runtime-Wechsel ein Ticket bei einem Hoster aufmachen musst, dessen Support erst nach 48 Stunden antwortet, ist aus einer 9.2 ein Kalenderproblem geworden. Dein Code hatte nichts zu reparieren.

Letzte Woche habe ich mit einer Freelancerin gesprochen (sie wollte nicht namentlich genannt werden), die rund dreißig Kundenseiten betreut. Am 20. Oktober konnte sie mir die Framework-Version jeder einzelnen aus dem Kopf sagen. Sie konnte mir aber nicht sagen, bei welchen sie PHP überhaupt aktualisieren durfte. Elf liefen auf Shared Hosting, wo die PHP-Version ein Dropdown ist, das jemand anderes befüllt. Vier lagen auf einem VPS, den eine frühere Agentur 2021 eingerichtet hatte, mit einem handkompilierten Build, an den sich niemand herantraute. Das ist keine Nachlässigkeit. Unser Tooling pflegt die composer.lock liebevoll und behandelt den Interpreter darunter wie das Wetter.

Der stärkste Einwand gegen das Modell der Vorankündigung verdient es, ernst genommen zu werden. Wer ein kritisches Release ohne Details ankündigt, signalisiert Angreifern womöglich, dass etwas Saftiges kommt, und alarmiert außerdem die Chefetage, die dann eine beängstigende Schlagzeile weiterleitet und fragt, ob man den Shop vom Netz nehmen sollte. Der Text von CERT-EU selbst hat den Besonnenen nicht gerade geholfen: Wo sich etwas nicht schnell beheben lässt, solle man erwägen, aus dem Internet erreichbare Anwendungen vom öffentlichen Netz zu trennen, bis ein Fix eingespielt ist. Schnell gelesen klingt das nach „alles ausstöpseln“, und ich habe mindestens einen Slack-Channel gesehen, der genau an dieser Lesart eskaliert ist.

Trotzdem finde ich, dass sich der Deal lohnt. Angreifer, die Quellbäume diffen können, erfahren vom Bug ohnehin in dem Moment, in dem der Patch erscheint, ob angekündigt oder nicht; die Vorankündigung ändert nur, wie gut die Verteidiger in diesem Moment vorbereitet sind. Und die Formulierung von CERT-EU ist aus gutem Grund konditional. Isolation ist der Notbehelf für eine Maschine, die du nicht patchen kannst, und das ist an sich schon das Eingeständnis, dass das eigentliche Versagen Monate früher passiert ist, als sich niemand für diese Maschine zuständig fühlte. Die Panik in diesem Slack-Channel kam daher, dass niemand die Antwort auf eine langweilige Frage kannte: Welche unserer Server vertragen heute einen neuen PHP-Build?

Was ich ändern würde, ist also überschaubar. Behandle das PHP-Binary wie eine Abhängigkeit mit Lockfile. Pinne es in deinem Container-Base-Image oder deiner Provisionierungskonfiguration, schick es durch denselben Pull-Request-Flow wie alles andere und lass deine CI die Testsuite gegen das nächste Patch-Release laufen, sobald es erscheint. Wenn dein Stack auf Docker läuft, ist das eine einzeilige Änderung an der FROM-Zeile und eine grüne Pipeline. Bei Shared Hosting ist es eine schriftliche Vereinbarung darüber, wie schnell der Hoster Security-Builds ausliefert, und diese Vereinbarung gehört in den Vertrag, gleich neben die Uptime-Zahl. Glamourös ist beides nicht, und genau darum geht es: Am 21. Oktober hatten die Teams, die so etwas hatten, ihren Rollout vor dem Mittagessen erledigt und stritten danach wieder über Namenskonventionen.

Das Advisory ist inzwischen öffentlich, also lies die tatsächlich betroffenen und gefixten Versionen auf php.net und bei deiner Distribution nach und gleich sie mit dem ab, was deine Webserver wirklich ausführen. Versionsnummern wiederhole ich hier bewusst nicht, denn der schnellste Weg, eine falsche zu verbreiten, ist eine Kolumne, die aus dem Gedächtnis geschrieben wurde. Mir geht es um den nächsten Fall. Es wird ein weiteres Security-Release mit festem Termin geben, und das PHP-Team wird uns sehr wahrscheinlich wieder den Gefallen einer Vorwarnung tun.

Also mal ehrlich: Wenn das nächste vorangekündigte kritische Release kommt, wie viele Stunden brauchst du, um eine gepatchte PHP-Runtime auf jeden Produktionshost zu bringen, für den du verantwortlich bist, und welcher einzelne Schritt in dieser Kette ist der langsamste?