PHP 7.4.33 (cli). Ich würde wetten, dass genau dieses Banner diese Woche noch auf erschreckend vielen Produktionsservern auftaucht. 7.4.33 war das letzte Release, das dieser Zweig je bekommen hat, und seit November 2022 gibt es für die 7.4er-Linie keine Sicherheitsfixes mehr. Behalt diesen Versionsstring im Kopf, während sich die Schlagzeilen über künstliche Intelligenz streiten, denn er entscheidet, ob CVE-2026-109618 und CVE-2026-109619 für dich bloß ein mieser Dienstag werden oder eine Meldung über einen Sicherheitsvorfall.

Das ist bisher berichtet worden: Zwei Lücken in der PHP-Engine, bewertet mit 9.2, erlauben Remote Code Execution ganz ohne Authentifizierung. Die Bugs sollen mehr als zehn Jahre alt sein, und für den Fix war offenbar ein größerer Eingriff in die Engine selbst nötig. Gefunden hat sie Wiz zusammen mit GPT-5.6 Sol von OpenAI, im Rahmen eines Programms namens Patch the Planet. Palo Alto Networks zählt mehr als 22.6 Millionen exponierte Instanzen. Nicholas Weaver sagte gegenüber Cybersecurity Dive, dass bereits Angriffe in freier Wildbahn beobachtet wurden. Details sind an einem Dienstag in sozialen Medien geleakt, deshalb kam das Notfall-Release einen Tag früher als geplant. Finnland hat seine öffentlichen staatlichen Dienste vom Netz genommen, die niederländische nationale Cybersicherheitsbehörde hat ihre eigene Website abgeschaltet, Websites französischer Präfekturen waren eine Zeit lang offline, und bei Wikimedia fielen kurzzeitig einige Systeme aus. Ich gebe das so weiter, wie es berichtet wurde. Gleich das Advisory auf php.net mit deinem eigenen Stack ab, bevor du irgendeiner Zusammenfassung aus zweiter Hand traust, diese hier eingeschlossen.

Die Zahl, zu der ich immer wieder zurückkomme, ist nicht 22.6 Millionen. Cisco schätzt, dass auf etwa der Hälfte der aus dem Internet erreichbaren Instanzen PHP-Versionen laufen, die so alt sind, dass sie überhaupt keine Sicherheitsupdates mehr bekommen. Für diese Server existiert der Notfall-Patch schlicht nicht. Es kommt kein Point-Release 7.2.35, das sie rettet. Die einzige Option ist ein Versionssprung, und ein Versionssprung auf einer Codebasis, die seit 2019 niemand angefasst hat, ist ein Projekt und kein Patch.

Das stärkste Gegenargument lautet, dass der KI-Aspekt tatsächlich die eigentliche Geschichte ist. Wenn ein Modell in ein paar Monaten einen zwölf Jahre alten Fehler in der Engine aufspüren kann, dann ist Bugsuche gerade für alle billig geworden, auch für Angreifer, und die Zeit zwischen Offenlegung und Ausnutzung wird weiter schrumpfen. Da stimme ich zu. Ich glaube nur nicht, dass es am Ergebnis etwas ändert. Stell dir vor, genau dieser Bug wäre auf die alte Art von einem menschlichen Forscher gefunden worden. Die Server, die auf nicht mehr unterstützten Zweigen festhängen, wären genauso exponiert, denn ihr Problem war nie, dass die Lücke unbemerkt blieb. Ihr Problem ist, dass sie kein Fix in weniger als einer Woche erreichen kann. Billigere Bugsuche erhöht den Druck auf diese Schwachstelle. Sie ist aber nicht die Schwachstelle.

Ich tue auch nicht so, als wäre das Upgrade einfach, dafür habe ich genug davon hinter mir, um zu wissen, wo es wehtut. Eine Legacy-App, die sich auf each() oder create_function() stützt, bricht unter PHP 8.0 schlicht zusammen, weil beide entfernt wurden. Die Deprecation dynamischer Properties in 8.2 flutet deine Logs mit Warnungen aus Vendor-Code, den du nicht geschrieben hast und nicht so leicht forken kannst. Und dann ist da noch die Extension, kompiliert gegen irgendein längst verschwundenes ABI, die genau eine Person verstanden hat, und diese Person ist 2021 gegangen. Einem Team, das so etwas durchgemacht hat, einfach „mach halt ein Upgrade“ hinzuwerfen, ist billiger Rat. Aber ein Wochenende mit Rector-Läufen und kaputten Fixtures kostet trotzdem weniger, als zu den Websites zu gehören, die eine Regierung vom Netz nehmen musste.

Ehrlich gesagt ist das eine der wenigen Stellen, an denen unser Ökosystem gut aussieht, wenn man ein Auge zudrückt. Die Engine hat einen tiefen, kniffligen Fix bekommen und ihn trotz Leak früher ausgeliefert, und genau so sollte ein Projekt funktionieren. Auseinander fällt es weiter unten in der Kette: bei Hosting-Images, die Minor-Versionen auf ewig pinnen, und bei Agenturverträgen, die den Bau einer Website abdecken, aber nie die Wartung. Eine Bekannte von mir, die Go schreibt, weist gern darauf hin, dass ihr Deployment aus einem einzigen Binary besteht. Stimmt, und trotzdem musste sie beim letzten Mal, als so etwas passiert ist, alles neu bauen und neu deployen, was gegen eine verwundbare Library gelinkt war. Jede Sprache hat dieses Problem. Unsere betreibt nur einen größeren Teil des Webs, also sehen wir es in größerem Maßstab.

Die Lehre, die ich aus dem Oktober ziehe, ist also nicht, dass KI beängstigend ist. Sondern dass „wir sind auf einem unterstützten Zweig“ eine dauerhafte Anforderung sein muss, so regelmäßig geprüft wie Backups, und keine Hoffnung, die jemand während eines Rewrites abnickt. Wenn dein ältester Produktionsserver nicht innerhalb einer Woche nach einem Advisory auf eine unterstützte Minor-Version wechseln kann, dann ist das dein eigentliches Risiko, egal wer oder was den nächsten Bug findet.

Und damit zu dem, was ich wirklich von dir hören möchte. Was hält deinen ältesten Produktionsserver auf seiner aktuellen PHP-Version fest: eine Extension, eine Major-Version des Frameworks, ein Kundenvertrag oder einfach, dass sich niemand zuständig fühlt? Und mal realistisch: Wie lange würdest du brauchen, um ihn auf einen unterstützten Zweig zu bringen, wenn das nächste Advisory morgen früh erscheint?