PHP 8.2: Sicherheitsupdates enden am 31. Dezember 2026

PHP 8.2 erhält laut PHP-Projekt noch bis zum 31. Dezember 2026 Sicherheitskorrekturen. Ab 2027 erscheinen für diesen Zweig keine neuen Sicherheitsfixes mehr. Ihre Anwendung läuft an diesem Datum weiter, doch neu gemeldete Schwachstellen können dann ungepatcht bleiben. Wer PHP 8.2 in einer Business-Anwendung betreibt, sollte den Wechsel vor Jahresende planen.

Was die Frist bedeutet

Die Frist bezieht sich auf den Support des PHP-Projekts. Ein Hosting-Anbieter kann eigene Sicherheitskorrekturen oder erweiterten Support anbieten. Fragen Sie nach, welche PHP-Versionen abgedeckt sind, wie lange die Korrekturen bereitstehen und wer sie installiert. Verlassen Sie sich nicht auf eine allgemeine Aussage wie "der Server wird gewartet".

Am 1. Oktober 2026 sieht der offizielle Zeitplan so aus:

• PHP 8.2 erhält nur noch Sicherheitskorrekturen, und zwar bis zum 31. Dezember 2026.
• PHP 8.3 erhält nur noch Sicherheitskorrekturen bis zum 31. Dezember 2027.
• PHP 8.4 ist aktiv unterstützt. Sicherheitskorrekturen sind bis zum 31. Dezember 2028 geplant.
• PHP 8.5 ist aktiv unterstützt. Sicherheitskorrekturen sind bis zum 31. Dezember 2029 geplant.

Die längste Supportfrist macht PHP 8.5 nicht automatisch zum richtigen Ziel. Framework, Composer-Pakete, Erweiterungen und Hosting müssen die Zielversion unterstützen. Wählen Sie die höchste Version, die Ihre Anwendung mit vertretbarem Aufwand zuverlässig betreiben kann.

Finden Sie jede PHP-8.2-Laufzeit

Beginnen Sie nicht nur mit der Startseite. Erfassen Sie alle Stellen, an denen PHP läuft: Webserver oder PHP-FPM, Container, Hintergrund-Worker, geplante Aufgaben, Importe und CI-Pipelines. Eine Anwendung kann im Browser eine andere PHP-Version nutzen als ein Cronjob.

php -v zeigt nur die Version der gerade aufgerufenen Kommandozeile. Vergleichen Sie den Wert mit der PHP-Version des Webprozesses und der Laufzeit in Produktionscontainern. Schreiben Sie auch auf, wer die jeweilige Umgebung aktualisieren darf.

Prüfen Sie die Zielversion

Lesen Sie die PHP-Anforderung in composer.json und prüfen Sie die tatsächlich installierten Versionen in composer.lock. Fragen Sie für Ihre Zielversion gezielt nach blockierenden Paketen, zum Beispiel mit composer why-not php 8.5. Prüfen Sie außerdem, ob das Framework und benötigte Erweiterungen wie intl, gd oder imagick in der Zielumgebung verfügbar sind.

Lassen Sie Composer und Ihre Tests mit genau der PHP-Version laufen, die später produktiv eingesetzt wird. composer check-platform-reqs findet fehlende Erweiterungen und abweichende Plattformanforderungen. Eine lokale Installation mit anderer PHP-Version belegt nicht, dass der Produktivserver passt.

Wechseln Sie in kontrollierten Schritten

Richten Sie zuerst eine Staging-Umgebung mit derselben PHP-Version, Konfiguration und denselben Erweiterungen wie in Produktion ein. Prüfen Sie dort die Abläufe, bei denen ein Fehler echte Folgen hat: Anmeldung und Rechte, Zahlungs- oder Rechnungslogik, Integrationen, Hintergrundjobs und geplante Aufgaben. Achten Sie auch auf neue Warnungen im Log.

Planen Sie den Rollback vor dem Release. Halten Sie das bisherige Deployment bereit und klären Sie, ob Datenbankänderungen mit der alten Version kompatibel bleiben. PHP-Version, Framework und Datenbankschema gleichzeitig umzustellen erschwert die Fehlersuche.

Nutzen Sie die verbleibenden Wochen für einen festen Ablauf. Erfassen Sie die Laufzeiten und Abhängigkeiten im Oktober. Beseitigen Sie inkompatible Pakete und testen Sie die Zielversion im November. Planen Sie den Produktivwechsel mit Zeit für Beobachtung und Korrekturen, statt bis zum 31. Dezember zu warten.

Wenn niemand sicher sagen kann, welche PHP-Version Ihre Anwendung im Betrieb nutzt, ist diese Bestandsaufnahme der erste Schritt. Die PHP-Modernisierung beschreibt, wie sich ein Versionswechsel für eine gewachsene Anwendung vorbereiten lässt.

Quelle: PHP Supported Versions.