Am Mittwoch, dem 21. Oktober 2026, hat das PHP-Projekt PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Diese Versionen beheben zwei kritische Sicherheitslücken in der Speicherverwaltung und der Fehlerbehandlung, also in Teilen von PHP, die nahezu jeder Request berührt. Falls du PHP betreibst und noch nicht aktualisiert hast: Bitte tu es jetzt.
Das zugrunde liegende Problem blieb zu lange ungelöst, und die PHP Foundation sagt selbst, warum: Der Entscheidungsprozess des Security Teams hat die Arbeit gebremst, und es fehlten die Ressourcen. Am zweiten Grund ändert der Hass, der in diesen Tagen über PHP ausgeschüttet wird, nichts, eine breitere Finanzierung der Arbeit an PHP dagegen schon.
Die Foundation benennt das Versagen selbst
In ihrem Beitrag zu diesem Release beschreibt die PHP Foundation, wie die Lücken gefunden und behoben wurden, und sie benennt offen, was dabei nicht gut gelaufen ist. Erste Anzeichen des Problems wurden schon 2024 bei einem externen Sicherheitsaudit gefunden, allerdings noch ohne einen konkreten Angriffsweg. Jeder mögliche Fix hatte seinen Preis, das Security Team entschied im Konsens, und es gab nur wenige, die die Engine tief genug kennen. So blieb die Behebung liegen, und die Foundation nennt das ein strukturelles Versagen.
Seit dem 11. August hatte der Fix für alle, die bei der Foundation an Sicherheit arbeiten, oberste Priorität, zuletzt auch an Wochenenden und rund um die Uhr. Jetzt liegt er für alle unterstützten Versionszweige vor. Für den Entscheidungsprozess kündigt die Foundation Änderungen an, damit Sicherheitsentscheidungen künftig mit Mehrheit fallen können.
Dafür danke ich allen Beteiligten: dem PHP Security Team, den Release Managern, den Paketverantwortlichen bei Distributionen und LTS-Anbietern sowie den Sicherheitsforschenden, die ihre Funde verantwortungsvoll gemeldet haben. Besonders danke ich Volker Dusch, Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka und Nora Dossche.
Das Embargo hielt nicht bis zum Release
Mich ärgert, dass die koordinierte Offenlegung auf den letzten Metern gestört wurde. Die CVE-IDs kursierten zwei Tage vor dem geplanten Termin mit falschen Angaben zu Zeitpunkt und Schweregrad, und das Projekt hat das Release daraufhin um einen Tag auf den Mittwoch vorgezogen. Eines der meldenden Unternehmen hat versehentlich ein Video seines Proof of Concept veröffentlicht. Ein Anbieter von Container-Images hat mehr als sechs Stunden vor dem Release Images mit dem Fix bereitgestellt und damit das Embargo gebrochen. Damit wurden Wochen sorgfältiger Abstimmung zwischen vielen Beteiligten entwertet.
Sicherheit braucht mehr Leute, die die Engine kennen
Noch mehr ärgert mich, dass diese Gelegenheit genutzt wurde, um Hass über PHP auszuschütten: über die Sprache, über die Menschen, die an ihr arbeiten, und über die, die sie verwenden. Sicherheitslücken gibt es in jeder Software dieser Größe und dieses Alters. Entscheidend ist, wie mit ihnen umgegangen wird. Daran gibt es in diesem Fall etwas zu kritisieren, und die Foundation hat es selbst getan.
Ich halte nichts davon, PHP zu verteidigen. Lieber schaue ich mir an, was die Sprache heute ist, und das habe ich in diesem Sommer zweimal getan: in Vier von fünf anhand der Kriterien des modernen Sprachdesigns und in Auch eine Sprache hat nichtfunktionale Anforderungen anhand derer, nach denen Architekturentscheidungen tatsächlich fallen.
Im zweiten Artikel geht es auch darum, dass ein großer Teil der bezahlten Arbeit an PHP von wenigen Sponsoren abhängt. Die elf Entwicklerinnen und Entwickler, die die Foundation beauftragt hat, haben 2025 rund 42 % aller Commits in php-src verfasst, und die Zahl der Sponsoren ist im Jahresvergleich gesunken. Der Beitrag der Foundation läuft auf dieselbe Feststellung hinaus, von der Seite der Sicherheit aus gesehen: Die Sicherheitsarbeit an PHP hängt an einer kleinen Gruppe von Entwicklerinnen und Entwicklern, die die Foundation bezahlt, und an ein wenig freiwilliger Hilfe.
Damit sind wir wieder bei der Verzögerung seit 2024. Einen Fix in der Speicherverwaltung der Engine können nur Leute schreiben und beurteilen, die diese Engine im Detail kennen. Dieses Wissen entsteht über Jahre der Arbeit an php-src, und einen großen Teil dieser Arbeit bezahlt heute die Foundation. Am Ende ihres Beitrags bittet sie deshalb Unternehmen, Hosting-Anbieter, Cloud-Plattformen, Distributionen und staatliche Stellen, sie zu finanzieren.
Ich bin Mitglied im Board der PHP Foundation, du kannst diese Bitte also auch als meine lesen. Wenn dein Unternehmen mit PHP Geld verdient, unterstütze die Foundation. Dann sind beim nächsten Problem dieser Art mehr Leute da, die es beheben können, bevor jemand von außen einen Angriffsweg vorführt.
