PHP 8.2 Supportende: Was Sie bis Ende 2026 erledigen sollten
PHP 8.2 erhält ab dem 01.01.2027 keine Sicherheitsupdates mehr vom PHP-Projekt. Ihre Website läuft danach weiter, neu entdeckte Lücken werden aber nicht mehr geschlossen. Planen Sie den Wechsel auf PHP 8.4 oder 8.5 für das zweite Halbjahr 2026 ein und testen Sie ihn vorher auf einer Kopie.
Am 01.01.2027 fällt keine Website aus. Ab diesem Tag bleibt aber jede neu entdeckte Lücke in PHP 8.2 offen, und mit jedem Monat steigt die Zahl der Pakete, die PHP 8.2 nicht mehr unterstützen. Betroffen sind CMS-Websites wie WordPress, Statamic oder TYPO3 ebenso wie eigene Anwendungen und Shops. Wer im Juli mit der Planung beginnt, hat genug Zeit für Tests, ohne dass die Umstellung in den Dezember fällt.
Zeitplan
Der Support-Zyklus von PHP
Jede PHP-Version wird vier Jahre gepflegt: zwei Jahre mit Fehlerbehebungen und Sicherheitsupdates, danach zwei Jahre nur noch mit Sicherheitsupdates. Seit einer Regeländerung im Jahr 2024 endet jede Phase am 31. Dezember. Das macht die Termine gut planbar.
Der Stand laut php.net:
PHP 8.2: erschienen im Dezember 2022, Sicherheitsupdates bis 31.12.2026
PHP 8.3: Sicherheitsupdates bis 31.12.2027
PHP 8.4: Fehlerbehebungen bis 31.12.2026, Sicherheitsupdates bis 31.12.2028
PHP 8.5: erschienen im November 2025, Sicherheitsupdates bis 31.12.2029
Wer zum Jahreswechsel umstellt, wählt deshalb 8.4 oder 8.5. Ein Sprung nur auf 8.3 verschafft ein Jahr und bringt denselben Testaufwand.
Risiko
Ab wann PHP 8.2 keine Sicherheitsupdates mehr bekommt
Mit dem Supportende am 31.12.2026 veröffentlicht das PHP-Projekt keine Korrekturen mehr für diese Version. Wird im Februar 2027 eine Lücke im Umgang mit Dateiuploads oder in einer der mitgelieferten Erweiterungen bekannt, gibt es für 8.2 keinen offiziellen Patch.
Eine Ausnahme gibt es: Linux-Distributionen pflegen ihre eigenen PHP-Pakete teils länger. Debian 12 liefert PHP 8.2 aus. Die reguläre Sicherheitsunterstützung von Debian 12 lief bis zum 11.07.2026, seitdem pflegt das Debian-LTS-Team die Pakete und portiert bis zum 30.06.2028 Sicherheitskorrekturen zurück. Läuft Ihre Website mit dem PHP-Paket von Debian 12, sind Sie also nicht sofort ungeschützt. Zwei Einschränkungen bleiben:
Viele Server nutzen nicht das Distributionspaket, sondern Pakete aus Fremdquellen, etwa von Ondřej Surý oder aus einem Hosting-Panel. Für diese gilt der Termin des PHP-Projekts.
Frameworks und Bibliotheken richten sich nach php.net. Laravel 13 setzt PHP 8.3 voraus, viele Pakete heben ihre Mindestversion mit dem Supportende an. Auf 8.2 bekommen Sie deren Sicherheitsupdates nicht mehr.
Auf Shared Hosting entscheidet der Anbieter. Manche stellen veraltete Versionen gegen Aufpreis weiter bereit, andere stellen Kunden automatisch um. Beides sollten Sie nicht dem Zufall überlassen.
Prüfen
So prüfen Sie Ihre PHP-Version
Prüfen Sie die Version, mit der die Website wirklich ausgeliefert wird, nicht nur die auf der Kommandozeile. Auf vielen Servern laufen mehrere PHP-Versionen parallel, und die Kommandozeile zeigt eine andere als der Webserver.
Je nach System:
WordPress: unter Werkzeuge, Website-Zustand, Reiter Bericht, Abschnitt Server.
Laravel: mit dem Befehl php artisan about auf dem Server, dazu einmal phpversion() über eine Route im Admin-Bereich, um die Webserver-Version zu sehen.
Statamic: im Control Panel unter Utilities, PHP Info.
Andere Systeme: eine temporäre Datei mit phpinfo(), die Sie nach dem Ablesen sofort wieder löschen.
Drei Stellen werden beim Prüfen oft übersehen:
Cronjobs und Warteschlangen: Sie laufen mit der Kommandozeilen-Version. Wird nur der Webserver umgestellt, laufen geplante Aufgaben weiter auf 8.2.
Die Datei composer.json: Steht dort unter config, platform eine feste PHP-Version, löst Composer Abhängigkeiten für diese Version auf, egal was auf dem Server läuft. Dieser Eintrag muss mit umgestellt werden.
Mehrere Websites auf einem Server: Eine alte Nebenseite, etwa eine Kampagnen-Seite von 2021, hält oft den ganzen Server auf der alten Version fest.
Umstellung
Was beim Wechsel auf eine neuere Version passiert
Ein Wechsel von 8.2 auf 8.4 ist bei gepflegtem Code ein überschaubarer Schritt. Die meisten Änderungen sind Hinweise auf veraltete Schreibweisen, sogenannte Deprecations, die erst in einer späteren Version zu Fehlern werden. Probleme machen fast immer alte Abhängigkeiten, nicht der eigene Code.
Ein Beispiel: Seit PHP 8.4 erzeugt eine Funktionsdefinition mit einem Typ und dem Standardwert null eine Deprecation-Meldung, weil der Typ nicht ausdrücklich als nullable markiert ist. Die Korrektur ist ein Fragezeichen vor dem Typ:
// Ab PHP 8.4 veraltet: Typ implizit nullable
function speichern(Kunde $kunde = null) {}
// Richtig: Typ ausdrücklich nullable
function speichern(?Kunde $kunde = null) {}
Die Website funktioniert weiter, aber die Logdateien füllen sich. In älteren Projekten kommt diese Schreibweise hundertfach vor, oft in eingebundenen Paketen, die seit Jahren niemand aktualisiert hat.
So gehen wir in der Website-Wartung bei einem Wechsel vor:
Version auf einer Staging-Umgebung umstellen, nicht auf dem Live-Server.
Abhängigkeiten mit Composer aktualisieren und Pakete ohne Unterstützung für die neue Version ersetzen.
Automatisierte Prüfungen laufen lassen, etwa Rector für Umschreibungen und PHPCompatibility für eine statische Prüfung.
Tests und eine manuelle Prüfung der wichtigsten Abläufe: Anmeldung, Formulare, Zahlungen, Exporte, Cronjobs.
Live umstellen, Fehlerprotokolle eine Woche lang täglich lesen.
Neben der Sicherheit bringt der Wechsel auch etwas für die Weiterentwicklung. PHP 8.4 führt Property Hooks und asymmetrische Sichtbarkeit ein, mit denen sich Datenklassen kürzer schreiben lassen, PHP 8.5 den Pipe-Operator für verkettete Funktionsaufrufe. Für Entscheider wichtiger: Aktuelle Versionen von Frameworks und Paketen setzen neuere PHP-Versionen voraus. Wer auf 8.2 bleibt, kann bald auch die eigenen Bibliotheken nicht mehr aktualisieren und sammelt so eine zweite Altlast an.
Wie viel Aufwand Sie einplanen sollten
Als grobe Größenordnung: Eine Website mit aktuellem CMS braucht wenige Stunden. Eine eigene Anwendung mit Tests braucht ein bis drei Tage. Alter Code ohne Tests, mit verlassenen Paketen, kann Wochen brauchen. Dann gehört der Wechsel in einen größeren Plan, wie wir ihn für Laravel im Beitrag Laravel 13: Was die neue Version für Ihr Projekt bedeutet beschreiben. Warum regelmäßige kleine Updates günstiger sind als seltene große, steht in Patch-Disziplin: Warum kleine Updates großen Schaden verhindern.
Kurz beantwortet
Häufige Fragen
-
Technisch ändert sich am 01.01.2027 nichts. PHP 8.2 läuft weiter, es kommen nur keine Korrekturen mehr hinzu. Das Risiko wächst mit jeder neu bekannten Lücke, und manche Hoster stellen veraltete Versionen nach einer Übergangszeit ab.
-
Bei einer gepflegten Website mit aktuellem CMS sind es wenige Stunden einschließlich Test. Eigene Anwendungen mit Tests brauchen meist ein bis drei Tage. Bei altem Code mit verlassenen Paketen hängt der Aufwand davon ab, wie viele Abhängigkeiten ersetzt werden müssen.
-
Beides ist eine gute Wahl. PHP 8.4 bekommt Sicherheitsupdates bis Ende 2028 und ist bei Paketen und Hostern breit unterstützt. PHP 8.5 verschafft ein weiteres Jahr, setzt aber voraus, dass alle eingesetzten Pakete die Version bereits unterstützen. Prüfen Sie das auf der Staging-Umgebung, bevor Sie sich festlegen.
PHP-Wechsel einplanen
In unseren Wartungsverträgen gehören PHP-Wechsel zum festen Ablauf: Prüfung auf Staging, Umstellung, Kontrolle der Logs.
Nachweise
Quellen und Stand
Stand: 20.07.2026. Termine laut php.net, Debian-Langzeitpflege laut debian.org, Anforderungen laut Laravel-Dokumentation.
Artikel teilen