Was beim PHP 8.2 EOL bis zum 31. Dezember 2026 zu tun ist

Was das PHP 8.2 EOL am 31. Dezember bedeutet

EOL steht für „End of Life“, also das Datum, ab dem eine Software von ihren Entwicklern nicht mehr gepflegt wird. Das PHP 8.2 EOL ist der 31. Dezember 2026. Danach veröffentlicht das PHP-Projekt für die Version 8.2 keine Sicherheitskorrekturen mehr. Anwendungen laufen unverändert weiter, neu entdeckte Schwachstellen in der Sprache selbst bleiben aber offen, solange niemand anderes sie schließt.

Wann endet der Support für PHP 8.2?

Die offizielle Übersicht auf php.net zu den unterstützten Versionen nennt für 8.2 drei Daten: Veröffentlichung am 8. Dezember 2022, aktiver Support bis 31. Dezember 2024, Sicherheitssupport bis 31. Dezember 2026.

2024 hat das PHP-Projekt per Abstimmung beschlossen, jede Version vier Jahre zu pflegen, zwei mit Fehlerkorrekturen und zwei nur mit Sicherheitsupdates, und das Ende immer auf den 31. Dezember zu legen. Die Regel gilt für alle Versionen ab 8.2, das PHP 8.2 End of Life fällt deshalb gut ein Jahr später als nach altem Rhythmus.

PHP2Shell zeigt, worum es geht

Am 21. Oktober 2026 hat das PHP-Projekt eine kritische Lücke geschlossen, die unter dem Namen PHP2Shell bekannt wurde (CVE-2026-109618, Schweregrad 9,2 von 10). Über sie können Angreifer auf nicht aktualisierten Servern unter bestimmten Konfigurationen ohne Anmeldung eigenen Programmcode ausführen. Behoben ist sie in den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12.

Für 8.2 kam der Patch noch rechtzeitig, weil die Lücke vor dem PHP 8.2 EOL bekannt wurde. Eine gleichartige Lücke im Januar 2027 bliebe in 8.2 offen. Solche Lücken sind kein Einzelfall: Über alle Softwareprodukte hinweg wurden zwischen Juli 2024 und Juni 2025 wurden im Schnitt 119 neue Schwachstellen pro Tag bekannt, rund 24 Prozent mehr als im Vorjahr (BSI, Die Lage der IT-Sicherheit in Deutschland 2025, 2025). Dazu kommt, dass KI-Werkzeuge inzwischen gezielt nach Sicherheitslücken suchen, auch in älterem Code.

Updates nach dem PHP 8.2 EOL: Distribution oder Hoster

Das Supportende des PHP-Projekts ist nicht zwingend das Ende aller Sicherheitsupdates. Linux-Distributionen und Hoster pflegen eigene Fassungen weiter, teils über Jahre, teils gegen Gebühr. Welcher dieser Wege für eine Anwendung gilt, hängt davon ab, wie PHP auf dem Server installiert ist.

Distributionen pflegen länger als das PHP-Projekt

Debian 12 liefert die Version 8.2 als Standard aus und wird im Rahmen des Langzeitsupports bis 30. Juni 2028 gepflegt. Das Debian-Paket für PHP 8.2 hat den Fix für PHP2Shell bereits erhalten (Version 8.2.35-1~deb12u1). Für Server mit Debian 12 verschiebt sich das EOL von PHP 8.2 damit voraussichtlich auf Mitte 2028, solange das LTS-Team das Paket weiter pflegt. Bei Red Hat Enterprise Linux 8 und 9 wird das PHP-8.2-Paket bis Mai 2029 versorgt.

Das gilt allerdings nur, wenn PHP aus den Paketquellen der Distribution stammt. Kommen die PHP-Versionen dagegen aus Fremdquellen oder laufen in Containern, folgt ihre Pflege deren eigenen Regeln.

Was kostet PHP Extended Support beim Hoster?

Auf Shared-Hosting-Paketen entscheidet der Anbieter, was nach dem PHP 8.2 EOL passiert. IONOS und STRATO etwa stellen veraltete Versionen nicht sofort ab, sondern führen sie als kostenpflichtigen PHP Extended Support weiter. Bei IONOS kostet das für PHP 8.1 laut Preisliste 7,81 Euro im Monat (Stand November 2026), bei STRATO läuft die Gebühr für 8.1 seit dem 2. März 2026. STRATO nennt öffentlich keinen Betrag, IONOS führt 8.2 in der Preisliste noch nicht.

Der Betrag wirkt klein, fällt aber jeden Monat an und endet erst mit dem Wechsel auf eine aktuelle Version.

Warum die Übergangslösung kein Dauerzustand ist

PHP Extended Support beim Hoster und Long-Term Support für PHP über die Distribution verschaffen Zeit, beseitigen aber nicht den Grund für den Wechsel. Frameworks und Bibliotheken verlangen nach und nach neuere Versionen, und spätestens dann lassen sich im laufenden Softwarebetrieb keine Sicherheitsupdates der Anwendung selbst mehr einspielen.

Auf welche Version wechseln: 8.4, 8.5 oder 8.6?

Die Wahl der Zielversion entscheidet darüber, wann nach dem PHP 8.2 EOL die nächste Frist kommt. PHP 8.3 bekommt Sicherheitsupdates bis Ende 2027, PHP 8.4 bis Ende 2028, PHP 8.5 bis Ende 2029. Ein Wechsel auf 8.3 verschafft also nur ein Jahr, ein Wechsel auf 8.4 oder 8.5 zwei bis drei.

Was Frameworks heute verlangen

Den Spielraum legt meist das eingesetzte Framework fest, denn seine Mindestanforderung bestimmt, welche Zielversionen überhaupt in Frage kommen. Neue Hauptversionen heben diese Grenze an, wie Laravel 13 und Symfony 8 zeigen. Die folgende Übersicht nennt den Stand vom November 2026:

• Laravel 13 setzt mindestens PHP 8.3 voraus
• Laravel 12 läuft auf 8.2 bis 8.5, mit Sicherheitsfixes bis Februar 2027
• Symfony 7.4 LTS läuft ab 8.2, Sicherheitsfixes bis November 2029
• Symfony 8 verlangt mindestens PHP 8.4
• TYPO3 14 unterstützt die Versionen 8.2 bis 8.5
• WordPress empfiehlt PHP 8.3 oder neuer

Symfony 7.4 und TYPO3 14 erzwingen den Wechsel also nicht, das Framework bleibt auf 8.2 lauffähig. Das ist trügerisch, denn sicher ist die Anwendung nur, wenn auch die Sprache darunter gepflegt wird.

Warum PHP 8.6 zum Jahreswechsel noch zu früh kommt

Dass PHP 8.6 am 19. November 2026 erscheinen soll, hilft für einen Wechsel bis Silvester wenig, denn erst nach der Veröffentlichung zeigt sich, welche Bibliotheken und Erweiterungen die neue Version offiziell unterstützen. Die Praxis hat sich dagegen schon auf 8.4 eingestellt: Laut den Packagist-Zahlen, die der Entwickler Brent Roose regelmäßig auswertet, lief im Juli 2026 der größte Anteil der Installationen über Packagist, das zentrale Paketverzeichnis für PHP, bereits auf 8.4 (32 Prozent), 8.2 kam noch auf 14 Prozent.

In der Regel ist 8.4 deshalb der naheliegende Schritt, 8.5 dort, wo alle Abhängigkeiten es bereits tragen. Ein späterer Sprung auf 8.6 lässt sich dann ohne Zeitdruck planen.

Vorbereitung auf das PHP 8.2 EOL in fünf Schritten

Ein geordneter Wechsel folgt einer festen Reihenfolge: erst wissen, was betroffen ist, dann prüfen, was bricht, dann testen und erst zuletzt die PHP-Version umstellen. Die Vorbereitung auf das PHP 8.2 EOL beginnt deshalb nicht am Server, sondern mit einer Liste. Die fünf Schritte sind:

☞ Anwendungen und Server mit der PHP-Version 8.2 erfassen
☞ Herkunft der Installation und Updatequelle klären
☞ Abhängigkeiten und Code gegen die Zielversion prüfen
☞ auf einer Kopie testen und Fehler beheben
☞ umstellen, beobachten und dokumentieren

Bestandsaufnahme: wo PHP 8.2 überall läuft

Bevor sich die PHP-Version aktualisieren lässt, muss klar sein, wo sie überall läuft, und diese Liste ist oft länger als gedacht. Neben der Website gehören dazu Kundenportale, Schnittstellen zu ERP oder Buchhaltung, zeitgesteuerte Hintergrundaufgaben und Werkzeuge, die einmal für einen Zweck gebaut wurden. Je System werden Version, Framework, Hoster oder Server und die verantwortliche Person notiert. Diese Liste ist zugleich die Grundlage für das Schwachstellenmanagement, das nach dem Wechsel weiterläuft.

PHP-Kompatibilität prüfen, bevor umgestellt wird

Statische Prüfwerkzeuge lesen den Quellcode und melden Stellen, die in der Zielversion nicht mehr funktionieren. PHPCompatibility, eine Erweiterung des Prüfwerkzeugs PHP_CodeSniffer, testet gegen eine festgelegte Zielversion, Rector kann viele Anpassungen automatisch vornehmen. Beide decken nicht alles ab. Um die PHP-Kompatibilität zu prüfen, reichen die Werkzeuge deshalb nicht: Auch die eingebundenen Bibliotheken, die Composer als Paketverwaltung von PHP lädt, müssen auf ihre Mindestversion durchgesehen werden.

Typische Bruchstellen zwischen 8.2 und 8.4

Für jede neue Version veröffentlicht php.net Migrationshinweise mit allen inkompatiblen Änderungen und veralteten Funktionen. Beim Sprung von 8.2 auf 8.4 sind zwei solcher Listen durchzuarbeiten, die für 8.3 und die für 8.4. Meldungen dieser Art bedeuten meist kleine Codeänderungen, summieren sich in älteren Anwendungen aber. Beispiele aus diesen Listen sind:

• Parameter, die implizit null erlauben, gelten ab 8.4 als veraltet
• die Konstante E_STRICT ist ab 8.4 veraltet
• mysqli_ping() und verwandte Funktionen sind ab 8.4 veraltet
• Fehler in Datumsfunktionen lösen ab 8.3 eigene Ausnahmen statt Warnungen aus

Testen, umstellen, dokumentieren

Eine Kopie der Anwendung auf der Zielversion zeigt, was die Prüfwerkzeuge übersehen haben. Erst wenn die wichtigsten Abläufe dort fehlerfrei laufen, lässt sich die PHP-Version umstellen. Danach werden die Fehlerprotokolle einige Tage beobachtet, und Version, Datum und Updatequelle kommen in die Bestandsliste. Wie Updates dieser Art langfristig in die Wartung von PHP-Anwendungen eingeplant werden, entscheidet über die Kosten der nächsten Frist.

Was das BSI für Software ohne Herstellersupport verlangt

Für Behörden und Betreiber kritischer Infrastrukturen ist das Supportende von PHP 8.2 nicht nur eine technische Frage. Organisationen, die nach dem IT-Grundschutz des BSI arbeiten oder von Auftraggebern danach geprüft werden, müssen den Weiterbetrieb nach dem PHP 8.2 EOL begründen können, nicht nur technisch absichern.

Für nicht mehr unterstützte Produkte verlangt der Baustein zum Patch- und Änderungsmanagement zuerst die Prüfung, ob sie dennoch sicher betrieben werden können, und fährt fort: „Ist dies nicht der Fall, DÜRFEN diese Hardware- oder Software-Produkte NICHT mehr verwendet werden.“ (BSI, IT-Grundschutz-Kompendium, Baustein OPS.1.1.3, 2023). Eine Distribution mit Langzeitsupport oder ein gebuchter PHP Extended Support liefert weiterhin Sicherheitsupdates und damit die Grundlage für diese Prüfung. Ohne eine solche Quelle fehlt sie.

Wenn der Wechsel bis Silvester nicht klappt

Nicht jede Anwendung lässt sich bis Jahresende umstellen, etwa wenn ein Altsystem auf einem nicht mehr gepflegten Framework läuft. Dann zählt, dass die Übergangslösung bewusst gewählt und festgehalten wird: welche Quelle die Updates liefert, bis wann sie gilt und bis zu welchem Termin der Wechsel erfolgt. Den Grundsatz dahinter hat BSI-Präsidentin Claudia Plattner in der Pressemitteilung zum BSI-Jahresbericht vom 11. November 2025 formuliert: „Nur, wer sich aktiv schützt, erhöht die Chancen, Gefährdungen zu entgehen oder Schadwirkungen zu minimieren.“

Das PHP 8.2 EOL ist damit weniger ein Stichtag als ein Prüfauftrag. Wer die Bestandsaufnahme jetzt macht, weiß im Januar, welche Anwendung sicher läuft, welche über eine Übergangslösung abgesichert ist und welche noch einen Termin braucht.