PHP 8.2 bekommt noch acht Wochen Sicherheitsupdates

Am 21. Oktober hat das PHP-Projekt zwei kritische Lücken geschlossen, über die sich ohne Anmeldung Code aus der Ferne ausführen lässt. Bekannt geworden sind sie unter dem Namen php2shell. Die Korrekturen kamen als PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wer PHP 8.1 oder älter betrieb, bekam keine dieser Versionen.

Genau diese Lage steht für PHP 8.2 jetzt im Kalender: Nach dem 31. Dezember 2026 liefert das PHP-Projekt dafür keine Sicherheitskorrekturen mehr.

Was im Oktober für alte Versionen kam

Das Advisory des PHP-Projekts ist dazu eindeutig: „PHP 8.1 and older no longer receive updates from the PHP project.“ Wegen der Schwere der Lücken gab es eine Ausnahme: minimale Quelltext-Backports für PHP 7.4, 8.0 und 8.1, gedacht für alle, die PHP selbst übersetzen oder keinen Anbieter mit Langzeitpflege haben.

Das ist kein fertiges Paket und keine Zusage für die nächste Lücke. Für die meisten Betreiber älterer Versionen blieben zwei Wege: auf die Distribution warten, sofern sie die Version noch pflegt, oder unter Zeitdruck aktualisieren.

Der nächste Termin steht fest

Laut der Liste der unterstützten Versionen auf php.net endet der Sicherheitssupport für PHP 8.2 am 31. Dezember 2026. Für PHP 8.3 endet er am 31. Dezember 2027, für 8.4 Ende 2028, für 8.5 Ende 2029. Ab dem 1. Januar ist PHP 8.2 bei der nächsten Lücke dort, wo PHP 8.1 im Oktober war.

Ein Supportende ist ein Termin, kein Ereignis. Wer ihn plant, macht ein Upgrade mit Tests. Wer ihn erst bei der nächsten Lücke bemerkt, macht dasselbe Upgrade nachts und ohne Tests.

Wo PHP überall läuft

PHP steckt nicht nur in der Website. Es läuft im Intranet, im Ticketsystem, im Wiki, in Nextcloud, in Monitoring-Oberflächen und in Fachanwendungen, die ein Anbieter mitsamt Laufzeit ausliefert. Vier Fragen klären, was bis Jahresende zu tun ist:

• Erst die Liste. Auf welchen Systemen läuft PHP, in welcher Version? Der Blick von außen reicht dafür nicht: Viele Server nennen ihre Version nicht, und das ist richtig so.
• Dann die Herkunft. Kommt PHP aus dem Paket der Distribution, aus einem fremden Paketverzeichnis, aus einem Container-Image oder vom Anbieter der Anwendung? Distributionen pflegen ihre Pakete nach eigenem Zeitplan, teils länger als das PHP-Projekt. Ob das für ein bestimmtes System gilt, steht beim Distributor, nicht auf php.net.
• Dann der Anbieter. Bei Fachanwendungen entscheidet der Hersteller, welche PHP-Version freigegeben ist. Die Frage gehört jetzt gestellt, nicht im Januar.
• Und der Zeitplan. Ein Upgrade braucht Tests in einer Umgebung, die der Produktion gleicht. Acht Wochen mit Feiertagen sind dafür nicht viel.

Wie isidaten das abbildet

isidaten führt einen gemeinsamen Katalog der Herstellersupport-Enden für Software und Betriebssysteme, Datenquelle ist endoflife.date. Das Modul Attack Surface Management liest bei Scans unter anderem aus dem Server- und dem X-Powered-By-Header, welche PHP-Version ein Webserver nennt, und gleicht sie mit dem Katalog ab. Endet der Support in weniger als 90 Tagen, steht dort „Support endet bald“; ohne Herstellersupport legt das Modul einen Befund an. Weist der Header auf ein Paket einer Linux-Distribution hin, bewertet isidaten nicht nach dem Zeitplan des PHP-Projekts, sondern kennzeichnet es als Distributionspaket, weil sonst ein Fehlalarm entstünde.

Für Server, deren Header nichts verrät, gleicht das Modul Schatten-IT die installierte Software aus dem Geräteinventar mit demselben Katalog ab.

Die Prüffrage

Auf wie vielen Ihrer Systeme läuft am 1. Januar 2027 PHP 8.2 oder älter, und wer hat für jedes entschieden, was bis dahin passiert?

Wer die Antwort erst bei der nächsten Lücke sucht, hat für ein geplantes Upgrade keine Zeit mehr.

Quellen

PHP-Projekt: Security advisory vom 21. Oktober 2026 (englisch), abgerufen am 1. November 2026.

PHP-Projekt: Supported Versions (englisch), abgerufen am 1. November 2026.

endoflife.date: PHP (englisch).