PHP 8.2 Supportende am 31.12.2026: Was Unternehmen jetzt tun müssen

Am 31. Dezember 2026 erhält PHP 8.2 die letzten Sicherheitsupdates. Ab dem 1. Januar 2027 werden neu entdeckte Sicherheitslücken in PHP 8.2 nicht mehr behoben. Ihre Anwendung läuft weiter wie bisher, nichts fällt über Nacht aus. Aber jede Lücke, die ab dann bekannt wird, bleibt offen.

Dieser Artikel erklärt, wer betroffen ist, wie Sie es in fünf Minuten prüfen und wie ein Update in der Praxis abläuft.

Was „Supportende“ bei PHP konkret bedeutet

Jede PHP-Version wird vier Jahre lang gepflegt: zwei Jahre mit Fehler- und Sicherheitskorrekturen, danach zwei Jahre nur noch mit kritischen Sicherheitsupdates. Danach ist Schluss.

Quelle: php.net/supported-versions. PHP 8.6 befindet sich aktuell im Release-Candidate-Stadium.

Für Sie heißt das:

• Sicherheit: Neue Schwachstellen in PHP selbst werden nicht mehr gepatcht.
• Hosting: Viele Hoster stellen veraltete Versionen nur noch gegen Aufpreis bereit oder schalten sie nach einer Frist ab.
• Abhängigkeiten: Composer-Pakete verlangen nach und nach neuere PHP-Versionen. Sicherheitsupdates für Ihre Bibliotheken lassen sich dann nicht mehr einspielen.
• Compliance: Bei ISO-27001-Audits, Pentests oder Kundenfragebögen ist eine nicht mehr unterstützte Laufzeitumgebung regelmäßig ein Befund.

Sind Sie betroffen? Der 5-Minuten-Check

Fragen Sie Ihr Team oder Ihren Dienstleister nach diesen vier Punkten:

1. Welche PHP-Version läuft in Produktion? Auf dem Server: php -v. Achtung: Die CLI-Version kann von der Version des Webservers (PHP-FPM) abweichen.
2. Was steht in der composer.json? Der Eintrag "php": "^8.2" oder ähnlich zeigt, wofür die Anwendung ausgelegt ist.
3. Welche Framework-Version nutzen Sie? Laravel 11 hat seit März 2026 keinen Sicherheitssupport mehr, Laravel 12 noch bis Februar 2027. Laravel 13 setzt mindestens PHP 8.3 voraus.
4. Gibt es automatisierte Tests? Davon hängt ab, wie sicher und schnell ein Update geht.

Läuft Ihre Anwendung auf PHP 8.2 oder älter, sollten Sie das Update jetzt planen.

Welches Ziel: PHP 8.3, 8.4 oder 8.5?

Mein Rat in den meisten Fällen: direkt auf PHP 8.4, wenn alle Abhängigkeiten es unterstützen, sonst auf 8.3.

• PHP 8.3 ist der kleinste Schritt, hat aber nur noch ein Jahr Sicherheitssupport. Sie stehen Ende 2027 wieder vor derselben Frage.
• PHP 8.4 bringt zwei weitere Jahre Ruhe und ist im Ökosystem inzwischen gut unterstützt.
• PHP 8.5 ist möglich, wenn Ihre Pakete bereits kompatibel sind. Für ältere Anwendungen mit vielen Abhängigkeiten ist das oft noch zu früh.

Wichtig: Das Ziel bestimmen nicht Sie allein, sondern Ihre Composer-Pakete. Ein einziges nicht gepflegtes Paket kann den ganzen Plan verschieben.

Was beim Update typischerweise bricht

Von 8.2 auf 8.3 oder 8.4 ist der Sprung überschaubar. Die meisten Probleme entstehen nicht durch PHP selbst, sondern drumherum:

• Deprecations, die zu Fehlern werden: Was jahrelang nur eine Warnung im Log war, kann in neueren Versionen echte Fehler auslösen. Dynamische Properties sind ein typisches Beispiel.
• Veraltete Composer-Pakete: Bibliotheken ohne Updates sind der häufigste Grund für Verzögerungen. Manche haben Nachfolger, manche ersetze ich durch wenige Zeilen eigenen Code.
• Erweiterungen und Server-Konfiguration: Fehlende oder anders konfigurierte PHP-Extensions fallen oft erst auf dem Server auf.
• Ungetestete Kernprozesse: Checkout, Login, Rechnungsstellung. Wo keine Tests existieren, fällt ein Fehler erst beim Kunden auf.

Werkzeuge wie PHPStan (statische Analyse) und Rector (automatisierte Code-Anpassung) finden den Großteil dieser Stellen, bevor sie live gehen. Den Rest finden Tests.

So läuft ein Update ohne Stillstand

Ein PHP-Update muss den Betrieb nicht unterbrechen. Der Ablauf, den ich in Projekten nutze:

1. Bestandsaufnahme: PHP-Version, Framework, alle Composer-Pakete mit Status und bekannten Sicherheitslücken.
2. Tests für die kritischen Pfade: Bevor irgendetwas geändert wird, sichere ich ab, was Geld verdient.
3. Automatisierte Anpassung: Rector und PHPStan erledigen die Routinearbeit, ich prüfe jede Änderung.
4. Update auf einer Kopie: Staging-Umgebung mit der neuen PHP-Version. Die Live-Anwendung läuft unverändert weiter.
5. Umstellung mit Rückweg: Erst wenn alles passt, wird umgeschaltet. Falls doch etwas auftaucht, gibt es einen definierten Weg zurück.

So habe ich zum Beispiel eine produktive E-Commerce-Plattform in mehreren Stufen von PHP 5.2 auf 8.2 gebracht, ohne Downtime und ohne Feature-Stopp, und bei leasingmarkt.de (AutoScout24-Gruppe) eine Laravel-Anwendung von Version 4.2 auf 8/9 migriert, ebenfalls ohne Ausfallzeit.

Wie viel Zeit bleibt?

Für eine gepflegte Anwendung mit aktuellen Paketen und Tests ist ein Update von 8.2 auf 8.4 oft eine Sache von Tagen. Für eine gewachsene Anwendung mit veralteten Paketen und ohne Tests eher von Wochen.

Weil das Jahresende mit Urlaub und Code-Freezes zusammenfällt, rate ich: Bestandsaufnahme im November, Umsetzung bis Mitte Dezember. Wer erst im Januar startet, betreibt eine Weile eine Version ohne Sicherheitssupport. Das ist kein Weltuntergang, aber ein Risiko, das Sie bewusst eingehen sollten und nicht aus Versehen.

Checkliste zum Mitnehmen

• Produktive PHP-Version (CLI und Webserver) ermittelt
• Framework-Version und deren Supportende geprüft
• Composer-Pakete auf Kompatibilität und bekannte Lücken geprüft (composer audit)
• Zielversion festgelegt (in der Regel PHP 8.4)
• Tests für Checkout, Login und andere Kernprozesse vorhanden
• Staging-Umgebung mit neuer PHP-Version eingerichtet
• Termin für die Umstellung vor dem 31.12.2026 gesetzt
• Hoster gefragt, ab wann die alte Version abgeschaltet oder teurer wird

Unsicher, wie groß der Aufwand bei Ihnen ist?

Genau dafür gibt es mein Legacy Audit: In zwei Wochen erhalten Sie eine vollständige Liste aller Abhängigkeiten mit Supportende und Sicherheitslücken, eine priorisierte Roadmap mit Aufwand in Wochen und eine klare Empfehlung. Festpreis €7.500 netto, für kleinere Codebasen als 3-Tages-Quickcheck für €2.500.

30-Minuten-Gespräch buchen – wenn ich nicht der Richtige bin, sage ich es Ihnen.