Ein Drittel der PHP-Sites läuft ohne Fixes, und 8.2 ist als Nächstes dran

Laut der Nutzungsstatistik von W3Techs vom 22. Oktober 2026 laufen 34,7 % der Websites mit PHP auf PHP 7 oder älter, und jede dieser Versionen hat ihr End of Life hinter sich. Am selben Tag zeigt die Seite der unterstützten Versionen auf php.net PHP 8.2 mit Sicherheits-Support bis zum 31. Dezember 2026: in 70 Tagen. Wenn du Kundenseiten, einen Shared-Hosting-Account oder eine alte interne App betreust, ist diese Woche der Moment herauszufinden, auf welcher Seite dieser Linie jede davon steht. Das Advisory zu den RCEs im PHP-Kern vom 21. Oktober hat gezeigt, was diese Linie kostet.

Was die Statistik sagt und was nicht

W3Techs meldet, dass PHP auf 69,3 % der Websites läuft, deren serverseitige Sprache sich erkennen lässt. Unter diesen PHP-Sites liegt Version 8 bei 65,3 %, Version 7 bei 26,9 %, Version 5 bei 7,7 % und Version 4 bei 0,1 %. Zu diesen Zahlen gehören zwei Einschränkungen. Die Statistik kann nur zählen, was von außen sichtbar ist; eine Site, die ihre PHP-Version versteckt, fehlt in der Aufschlüsselung. Und sie nennt nur Hauptversionen: Die 65,3 % für „8“ enthalten 8.0 und 8.1, die schon am Ende sind, und 8.2, das nur noch Wochen hat. Der tatsächliche EOL-Anteil liegt also bei mindestens 34,7 %.

In der Regel überlebt altes PHP aus ganz gewöhnlichen Gründen: Ein Shared Hoster hält eine alte Version vor, damit nichts kaputtgeht, eine Agentur hat eine Site vor Jahren übergeben und niemand kümmert sich um ihre Upgrades, oder ein Plugin oder Paket hat die Runtime festgenagelt und wurde nie ersetzt. Nichts davon sieht man im Browser, und genau deshalb läuft es weiter.

Was „nur noch Sicherheits-Support“ heißt

php.net gibt jedem Branch ab dem ersten stabilen Release zwei Jahre aktiven Support, danach zwei weitere Jahre nur kritische Sicherheitsfixes, veröffentlicht nach Bedarf, und dann End of Life. Nur Sicherheit heißt: Gewöhnliche Bugs bleiben, wie sie sind; nur ernste Lücken bekommen ein Release. Nach dem Enddatum kommt gar nichts mehr. Das Projekt formuliert es selbst so: Wer ein Release nach End of Life nutzt, kann ungepatchten Sicherheitslücken ausgesetzt sein.

Das Advisory vom Oktober ist ein gutes Beispiel. Darin steht, dass PHP 8.1 und älter keine Updates mehr vom PHP-Projekt bekommen. Wegen der Schwere hat das Security-Team trotzdem minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht, nur für dieses eine Release und nur für alle, die PHP selbst aus den Quellen bauen. Meine Lesart, die eine Schlussfolgerung ist und kein Versprechen von irgendwem: Plane nicht damit, dass sich das wiederholt.

Ein Upgrade-Plan mit Daten

Die Daten stammen direkt von php.net. 8.3 bekommt Sicherheitsfixes bis zum 31. Dezember 2027. 8.4 ist bis zum 31. Dezember 2026 im aktiven Support und bekommt Sicherheitsfixes bis zum 31. Dezember 2028. 8.5 ist bis zum 31. Dezember 2027 im aktiven Support und bekommt Sicherheitsfixes bis zum 31. Dezember 2029. Für eine Site, die heute auf 8.2 läuft, ist 8.4 oder 8.5 das sinnvolle Ziel; ein Wechsel auf 8.3 bringt ein Jahr und bedeutet, das Ganze bald noch einmal zu machen. Bevor du die Runtime umstellst, prüf, ob die Abhängigkeiten des Projekts sie akzeptieren:

# the version the command line runs
php -r 'echo PHP_VERSION, PHP_EOL;'
# run under the target PHP: do the dependencies accept it?
composer check-platform-reqs

Denk daran, dass Kommandozeile und Webserver unterschiedliche PHP-Versionen nutzen können; prüf also auch die, die die Requests bedient.

Wenn jemand anderes den Server betreibt, stell drei Fragen schriftlich. Welche PHP-Version nutzt die Site in Produktion für Web-Requests? An welchem Datum wechselt sie auf 8.4 oder 8.5? Wer spielt PHP-Sicherheitsreleases ein, und wurden die Releases vom 21. Oktober eingespielt?

Der nächste Schritt für heute: Liste deine Sites auf, schreib zu jedem Namen die PHP-Version, die sie ausliefert, und gib jedem Eintrag unter 8.3 ein Upgrade-Datum vor Jahresende. Quelle: php.net, unterstützte Versionen.