Die Warnung von The Verge ist ungewöhnlich direkt: Eine kritische Lücke in PHP, der Sprache, die einen großen Teil des öffentlichen Webs rendert, könne Websites noch heute vom Netz nehmen. Ob der Schaden durch Ausnutzung oder durch einen übereilten Patch entsteht – der Satz beschreibt etwas Strukturelles an PHP, das keine Codeprüfung repariert. Das Ökosystem patcht langsam, und wenn es patcht, dann alles gleichzeitig.
PHP ist kein Produkt. Es ist eine Familie von Laufzeiten: der Build, den die Linux-Distribution ausliefert, der Build, den das Hosting-Panel festnagelt, der Build in einem vor zwei Jahren gebauten Container-Image und der, den der "einfache Installer" eines Plugins mitbringt. W3Techs führt PHP seit Langem bei rund drei Vierteln der Websites, deren serverseitige Sprache sich bestimmen lässt, und WordPress allein stellt einen großen Teil aller Sites im Internet. Wenn eine Lücke in die Laufzeit fällt, ist der Radius nicht die Installationsbasis eines Produkts, sondern der Standard-Stack des Webs.
Die Asymmetrie ist vertraut und bleibt brutal. Ein Angreifer braucht eine erreichbare Instanz und einen funktionierenden Exploit. Ein Verteidiger braucht jede Instanz gepatcht, jedes VM-Image neu gebaut und jeden Kunden auf Shared Hosting in einem Wartungsfenster, das jemand anders terminiert. Massenscanning beginnt typischerweise Stunden nach Veröffentlichung eines Proof of Concept, und das Fenster zwischen Advisory und internetweiter Suche schrumpft seit einem Jahrzehnt.
Der operative Rat ist unspektakulär und der einzige, der funktioniert. Erfasse, was tatsächlich PHP ausführt und in welcher Version. Teste das Update gegen die echte Anwendung, nicht gegen ein Hello-World. Patche. Wo das sofort nicht geht, stelle eine kompensierende Kontrolle vor die Exposition: eine WAF-Regel, einen virtuellen Patch, ein abgeschaltetes Feature. Beobachte die Fehlerraten während des Rollouts, denn eine schlechte Wechselwirkung mit einer Extension nimmt eine Site so wirksam vom Netz wie ein Exploit. Und wer Managed Hosting nutzt, sollte den Anbieter direkt fragen, ob und wann er abgedeckt ist. "Wir machen die Updates" ist keine Antwort auf "Sie sind auf dem gepatchten Build".
In der Auto-Update-Maschinerie steckt eine längere Lehre. Derselbe Mechanismus, der einen Hoster in einem Nachmittag Millionen Sites patchen lässt, würde ein kompromittiertes Update dasselbe tun lassen. PHPs Long-Tail-Problem ist kein Mangel an Patches. Es ist der Mangel an jemandem, der weiß, was installiert ist, in welcher Version, hinter welchem Plugin, für welchen Kunden. Diese Inventarlücke macht aus einem Routine-Advisory eine schlechte Woche.
Die Details der Offenlegung – betroffene Versionen, der genaue Auslöser, die von den Maintainern empfohlenen Maßnahmen – gehören ins Advisory und nicht in eine Zusammenfassung, und sollten dort gelesen werden, bevor jemand handelt. Ohne Einschränkung lässt sich sagen: Die Uhr lief los, als die Warnung rausging, und sauber durchkommen werden die Sites, die schon wussten, was sie betreiben.
