Kurz gesagt: PHP End of Life bedeutet: Das PHP-Projekt liefert für diesen Zweig keine Sicherheitsupdates mehr. PHP2Shell zeigt die Folgen deutlich, denn für PHP 8.1 und älter gibt es keinen offiziellen Fix, und PHP 8.2 endet am 31.12.2026. Wer heute auf einem alten Zweig läuft, sollte den Umstieg jetzt planen, nicht erst beim nächsten Notfall.
Was PHP End of Life bedeutet
Jeder PHP-Zweig, etwa 8.2 oder 8.3, wird vom PHP-Projekt nur für einen begrenzten Zeitraum gepflegt. Zuerst gibt es Fehlerbehebungen und Sicherheitsupdates, später nur noch Sicherheitsupdates. Danach endet die Unterstützung vollständig. Die aktuellen Zeiträume veröffentlicht php.net auf der Seite zu den unterstützten Versionen.
Nach dem Supportende läuft die Software zwar weiter. Wird aber eine neue Lücke bekannt, gibt es vom PHP-Projekt keinen Patch mehr. Der Server bleibt verwundbar, bis jemand anderes nachbessert oder bis Sie auf einen unterstützten Zweig wechseln.
Für Geschäftsführung und IT-Leitung ist das vor allem eine Planungsfrage. Eine Migration lässt sich in Ruhe vorbereiten. Unter Zeitdruck nach einer kritischen Meldung wird sie teuer und riskant.
Was PHP2Shell über veraltete Versionen zeigt
Am 21.10.2026 hat das PHP-Projekt Patches für zwei kritische Lücken veröffentlicht, CVE-2026-109618 und CVE-2026-109619. Beide erlauben die Ausführung von Schadcode aus der Ferne ohne Anmeldung und sind mit CVSS v4.0 9.2 bewertet. Laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen.
| Zweig | Status laut PHP-Projekt | PHP2Shell-Fix |
|---|---|---|
| PHP 8.5 | unterstützt | 8.5.12 |
| PHP 8.4 | unterstützt | 8.4.27 |
| PHP 8.3 | unterstützt | 8.3.36 |
| PHP 8.2 | unterstützt bis 31.12.2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | keine offiziellen Updates | nur minimale Quell-Backports |
| PHP 7.3 und älter | keine offiziellen Updates | kein Backport vom PHP-Projekt |
Für 8.1 und älter bleibt damit nur der Weg über Backports von Distributionen oder Hostern. Diese zeigen oft weiterhin die alte Versionsnummer an, obwohl sie gepatcht sind. Ob ein Backport eingespielt ist, kann nur der Anbieter verbindlich bestätigen. Einzelheiten stehen auf der Seite PHP 8.1 und älter: Was jetzt gilt, die vollständige Übersicht unter Welche PHP-Versionen sind betroffen?.
PHP 8.2 hat den PHP2Shell-Fix noch erhalten, erreicht aber am 31.12.2026 das Supportende. Wer jetzt von 8.1 migriert, sollte direkt einen neueren Zweig ansteuern.
Die Risiken veralteter PHP-Versionen im Überblick
Das Sicherheitsrisiko steht im Vordergrund, ist aber nicht das einzige. Veraltete PHP-Versionen ziehen weitere Probleme nach sich:
- Keine Patches für neue Lücken: Jede künftige Schwachstelle bleibt offen oder hängt von Backports Dritter ab.
- Veraltete Bibliotheken: Aktuelle Pakete setzen neuere PHP-Zweige voraus. Sicherheitskorrekturen in Bibliotheken lassen sich dann nicht mehr einspielen, wie der Ratgeber composer audit zeigt.
- Abhängigkeit vom Anbieter: Hoster berechnen für alte Versionen teils Aufpreise oder stellen den Betrieb ein. Die Frist bestimmt dann der Anbieter, nicht Sie.
- Nachweisprobleme: Gegenüber Versicherern, Auftraggebern oder bei Audits lässt sich eine nicht unterstützte Version schwer begründen. Ob daraus vertragliche oder rechtliche Folgen entstehen, klären Sie mit Versicherer oder Anwalt.
- Wachsender Migrationsaufwand: Je größer der Abstand zur aktuellen Version, desto mehr Code muss angepasst werden.
Besonders häufig betroffen sind ältere Shopsysteme und lange nicht angefasste Individualentwicklungen. Ein typisches Beispiel ist Shopware 5, das oft noch auf älteren PHP-Zweigen läuft.
Bestandsaufnahme: Welche PHP-Versionen laufen bei Ihnen?
Der erste Schritt ist ein vollständiges Bild. Auf vielen Servern laufen mehrere PHP-Versionen parallel, etwa für eine alte Website, die niemand mehr auf dem Schirm hat. Diese Befehle lesen nur:
# Version der Kommandozeile
php -v
# Installierte Versionen unter Debian/Ubuntu
ls /etc/php/
# Installierte Versionen in Plesk
ls /opt/plesk/php/ 2>/dev/null
# Laufende PHP-Prozesse mit Version im Namen
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Halten Sie für jede Website fest: Domain, PHP-Version, Betriebsart, CMS mit Version, verantwortliche Person. Diese Liste ist zugleich die Grundlage für Ihren Notfallplan. Im Shared Hosting finden Sie die Versionen meist im Kundenmenü des Hosters.
Migration planen: So gehen Sie vor
Eine Migration auf einen unterstützten Zweig folgt in der Regel denselben Schritten, unabhängig vom System:
- Ziel festlegen: einen Zweig wählen, der laut php.net noch möglichst lange unterstützt wird und laut Systemanforderungen des Herstellers zu Ihrem CMS passt.
- Kompatibilität prüfen: CMS, Erweiterungen, Themes und eigener Code. Die Angaben stehen auf der offiziellen Seite des jeweiligen Herstellers.
- Staging aufsetzen: eine Kopie der Website mit der neuen PHP-Version, inklusive Datenbank.
- Testen: alle wichtigen Abläufe, vom Kontaktformular bis zum Bestellprozess, dazu das Fehlerlog auf Warnungen.
- Umstellen und neu starten: Version wechseln, alle PHP-Prozesse neu starten, Funktion und Fehlerlog prüfen.
Planen Sie realistisch. Eine kleine Website mit aktuellem CMS ist oft schnell umgestellt. Ein über Jahre gewachsener Shop mit vielen Erweiterungen und eigenem Code kann dagegen eine Anpassung von Code und Erweiterungen erfordern, bis hin zum Wechsel auf eine neue Hauptversion des Shopsystems. Klären Sie früh, wer intern entscheidet, welches Budget bereitsteht und ob externe Entwickler eingebunden werden müssen.
Legen Sie außerdem fest, wie Sie künftig Supportenden im Blick behalten. Ein fester Termin im Jahr, an dem Sie die Liste Ihrer Websites mit den Angaben auf php.net abgleichen, verhindert, dass derselbe Engpass in zwei Jahren erneut entsteht.
Bis zur Umstellung sollten Sie die Übergangsmaßnahmen von php.net nutzen, etwa session.upload_progress.enabled=0 in der Serverkonfiguration. Sie sind kein vollständiger Schutz, senken aber das Risiko.
Wie hilft PHP SOS konkret?
- Wir erfassen alle PHP-Versionen, Betriebsarten und Anwendungen auf Ihren Servern.
- Wir bewerten das Risiko je Website und legen mit Ihnen Reihenfolge und Zielversion fest.
- Wir setzen bis zur Migration Übergangsmaßnahmen um und holen Bestätigungen zu Backports beim Anbieter ein.
- Wir migrieren über eine Staging-Umgebung und dokumentieren Test und Umstellung.
Den Ablauf beschreibt die Leistung PHP 8.1 und älter: Migration auf eine unterstützte Version.
Häufige Fragen
Wann endet die Unterstützung für PHP 8.2?
PHP 8.2 erreicht am 31.12.2026 das Ende der Unterstützung durch das PHP-Projekt. Den PHP2Shell-Fix hat der Zweig noch mit Version 8.2.35 erhalten, für spätere Lücken ist danach kein offizielles Update mehr zu erwarten.
Bekommt PHP 8.1 einen Patch gegen PHP2Shell?
Vom PHP-Projekt gibt es für 8.1 und älter keine offiziellen Updates mehr. Es existieren nur minimale Quell-Backports für 7.4, 8.0 und 8.1. Ob und wie Ihr Hoster oder Ihre Distribution diese einspielt, müssen Sie beim Anbieter erfragen.
Ist eine alte PHP-Version mit Backports des Hosters sicher?
Backports können konkrete Lücken schließen, ersetzen aber keinen unterstützten Zweig. Sie hängen vom Anbieter ab, kommen oft später und decken nicht jede Lücke ab. Als Dauerlösung sind sie daher ungeeignet.
Woher weiß ich, ob mein CMS mit einer neuen PHP-Version läuft?
Prüfen Sie die Systemanforderungen auf der offiziellen Seite des Herstellers und testen Sie in einer Staging-Umgebung. Bei Erweiterungen und Themes gilt dasselbe, denn sie sind oft der eigentliche Engpass.