Eine PHP-Version erreicht irgendwann ihr End of Life (EOL) -- ab diesem Tag erscheinen keine Sicherheitsfixes mehr, auch nicht für kritische, aktiv ausgenutzte Lücken. Genau das ist Ende 2025 PHP 8.1 passiert (endoflife.date). Trotzdem laufen 35,5 Prozent aller PHP-Websites noch auf der EOL-Reihe PHP 7.x (W3Techs, 2026), und allein PHP verarbeitet die serverseitige Logik von 72,4 Prozent aller Websites mit bekannter Programmiersprache (W3Techs, 2026). Wer den Wechsel verschleppt, betreibt seinen Shop mit Software, die niemand mehr patcht. Dieser Leitfaden zeigt, wie sich PHP-Upgrades planbar und kontrolliert umsetzen lassen -- mit Code-Audit, Staging-Tests und Rollback-Absicherung statt riskantem Versionssprung auf gut Glück.
Das Wichtigste in Kürze
- Eine PHP-Reihe durchläuft aktiven Support, dann ein Jahr Security-Only und schließlich End of Life, ab dem keine Patches mehr erscheinen. PHP 8.1 ist seit dem 31.12.2025 EOL, und 35,5 Prozent aller PHP-Sites laufen noch auf der EOL-Reihe 7.x (W3Techs, 2026).
- Gepflegt werden 2026 nur PHP 8.2, 8.3, 8.4 und 8.5 (php.net); Sicherheitsfixes gibt es für 8.3 bis Ende 2027 und für 8.4 bis Ende 2028. Neuere Reihen sind zudem schneller: PHP-Code läuft auf 8.3 rund 20 bis 40 Prozent schneller als auf 7.4 (Kinsta, 2026).
- Ausgenutzte Schwachstellen waren zuletzt bei rund 20 Prozent aller Datenpannen der Erstzugang, ein Anstieg um 34 Prozent (Verizon DBIR, 2025); die Median-Zeit bis zur Massenausnutzung lag bei null Tagen, das Schließen dauerte im Median 32 Tage.
- Vor dem Versionswechsel steht das Code-Audit: statische Analyse gegen die Zielversion, Kompatibilitätsmatrix je Erweiterung, Deprecation-Report und Composer-Abgleich. Erweiterungen und individuelle Plugins sind die häufigste Ursache gescheiterter PHP-Upgrades.
- Getestet wird auf einem Staging-Klon mit gleicher Datenbasis, gleichen Erweiterungen und anonymisierten Personendaten; freigegeben wird die Zielversion erst, wenn Checkout, Suche, Warenkorb, Kundenkonto und alle Schnittstellen ohne Beanstandung arbeiten.
- Zum Go-Live gehören ein frischer Snapshot von Datenbank und Dateien, ein auf Staging geprobtes Rollback und Monitoring mit definierten Abbruch-Schwellen; danach wird der nächste EOL-Termin fest im Wartungsrhythmus eingeplant (BSI IT-Grundschutz OPS.1.1.3).
Was End of Life bei PHP konkret bedeutet
Jede PHP-Hauptversion durchläuft einen festen Lebenszyklus mit drei Phasen. In der Phase des aktiven Supports (rund zwei Jahre) erhält eine Version sowohl Bugfixes als auch Sicherheitspatches. Danach folgt ein Jahr Security-Only: Es fließen ausschließlich noch Sicherheitskorrekturen, normale Fehler bleiben offen. Am Ende steht das End of Life -- ab diesem Stichtag veröffentlicht das PHP-Projekt keinerlei Patches mehr, auch nicht für schwerwiegende Schwachstellen (php.net).
Die Konsequenz ist eindeutig: Eine EOL-Version sammelt mit jeder neu entdeckten Lücke ungepatchte Angriffsfläche an. PHP 7.4 etwa erhält seit Ende 2022 keine Sicherheitsfixes mehr (endoflife.date) und ist damit gegenüber mehreren öffentlich dokumentierten CVEs dauerhaft verwundbar. Cybersecurity-Researcher fanden zeitweise mehr als 80.000 im Netz erreichbare, verwundbare PHP-Server (Cybernews, 2025). Eine veraltete PHP-Version ist deshalb kein theoretisches Restrisiko, sondern ein konkretes, das Angreifer aktiv abscannen.
PHP 8.1 ist seit dem 31.12.2025 EOL
Der PHP-Support-Fahrplan 2026 auf einen Blick
Um Upgrades sinnvoll zu planen, braucht es einen klaren Blick auf die offiziellen Support-Fenster. Stand 2026 werden nur noch vier PHP-Reihen gepflegt: 8.2, 8.3, 8.4 und 8.5 (php.net). Alles ab PHP 8.1 abwaerts ist End of Life. Die folgende Übersicht zeigt, welche Version wie lange Sicherheitsfixes erhält -- daraus ergibt sich automatisch das Zeitfenster, in dem ein Upgrade abgeschlossen sein sollte.
| PHP-Version | Status (2026) | Sicherheitssupport bis | Empfehlung |
|---|---|---|---|
| PHP 7.4 | End of Life | beendet (2022) | Dringend wechseln |
| PHP 8.0 | End of Life | beendet | Dringend wechseln |
| PHP 8.1 | End of Life | beendet (31.12.2025) | Wechsel einplanen |
| PHP 8.2 | Security-Only | 31.12.2026 | Upgrade vorbereiten |
| PHP 8.3 | Security-Only | 31.12.2027 | Solides Ziel |
| PHP 8.4 | Aktiver Support | 31.12.2028 | Zukunftssicheres Ziel |
Die Datumsangaben stammen aus den offiziellen Quellen php.net und endoflife.date (2026). Daraus folgt eine einfache Planungsregel: Wer heute migriert, sollte mindestens PHP 8.3 anpeilen -- diese Reihe erhält noch bis Ende 2027 Sicherheitsfixes und verschafft damit Puffer für den nächsten Zyklus. PHP 8.4 als aktiv unterstützte Version ist das zukunftssicherere Ziel, sofern alle installierten Erweiterungen sie bereits unterstützen.
Warum aufgeschobene Upgrades teurer werden
Es gibt einen verbreiteten Trugschluss: Solange der Shop läuft, scheint ein PHP-Upgrade unnötig. Tatsächlich wächst das Risiko mit jedem Monat, den eine EOL-Version weiterläuft. Der aktuelle Verizon Data Breach Investigations Report verzeichnet einen Anstieg der Schwachstellen-Ausnutzung als Erstzugang um 34 Prozent und beziffert deren Anteil an allen Breaches auf rund 20 Prozent (Verizon DBIR, 2025). Ungepatchte Software ist damit eines der häufigsten Einfallstore überhaupt.
Hinzu kommt die Zeitkomponente: Bei neuen, kritischen Schwachstellen an exponierten Systemen lag die mittlere Zeit von der Veröffentlichung bis zur Massen-Ausnutzung zuletzt bei null Tagen -- Angriffe begannen also am Tag der Bekanntgabe (Verizon DBIR, 2025). Gleichzeitig brauchten Organisationen im Median 32 Tage, um solche Lücken zu schließen (Verizon DBIR, 2025). Bei einer EOL-Version verschärft sich das Bild noch, weil überhaupt kein offizieller Patch erscheint, der eingespielt werden könnte.
Auch technisch wird das Aufschieben teurer. Je größer der Versionsrückstand, desto mehr Deprecations und Breaking Changes haben sich angesammelt, desto wahrscheinlicher sind inkompatible Erweiterungen -- und desto eher wird aus einem einfachen Upgrade ein aufwendiges Migrationsprojekt. Regelmäßige, kleinere Schritte sind planbarer und günstiger als der erzwungene Großsprung, wenn der Hoster eine veraltete PHP-Version irgendwann abschaltet.
Die Faustregel für planbare Upgrades
Code-Audit: Kompatibilität vor dem Upgrade prüfen
Ein PHP-Upgrade beginnt nicht mit dem Versionswechsel, sondern mit einer Bestandsaufnahme des Codes. Zwischen den Hauptversionen entfernt PHP regelmäßig veraltete Funktionen, verschärft die Typprüfung und aktiviert zuvor angekündigte Deprecations. Code, der auf PHP 7.4 ohne Beanstandung lief, kann auf 8.3 Warnungen oder fatale Fehler werfen. Das Audit identifiziert diese Stellen, bevor sie im Live-Betrieb auffallen. Ein konkretes Beispiel ist die kritische PHP-CGI-Lücke CVE-2024-4577 mit einem CVSS-Wert von 9,8 (NVD), die unmittelbar nach Bekanntwerden ausgenutzt wurde (Akamai, 2024) -- ein klarer Beleg, wie schnell aus einer veralteten Konfiguration ein reales Problem wird.
Praktisch lässt sich dieser Schritt automatisieren. Statische Analysewerkzeuge durchsuchen den gesamten Quellcode -- inklusive eigener Plugins, Theme-Anpassungen und Integrationen -- nach Konstrukten, die in der Zielversion nicht mehr funktionieren. Das Ergebnis ist eine priorisierte Liste der notwendigen Anpassungen. Besonders bei Shopware-Shops mit individuellen Erweiterungen liefert dieser Bericht die Grundlage für eine realistische Aufwandsschätzung.
Statische Code-Analyse
Werkzeuge prüfen den gesamten Quellcode gegen die Zielversion und melden entfernte Funktionen, Deprecations und Typkonflikte vor dem Upgrade.
Erweiterungs-Matrix
Für jede installierte Erweiterung wird die Kompatibilität mit der Ziel-PHP-Version dokumentiert: kompatibel, Update nötig oder Ersatz erforderlich.
Deprecation-Report
Angekündigte Abkündigungen werden früh sichtbar, damit Anpassungen geplant statt unter Zeitdruck im Störfall erfolgen.
Versions-Strategie
Statt eines Sprungs von 7.4 auf 8.4 wird ein etappenweiser Pfad über Zwischenversionen definiert, jede einzeln verifiziert.
Abhängigkeiten prüfen
Composer-Pakete und Bibliotheken werden auf Kompatibilität mit der neuen PHP-Reihe abgeglichen und bei Bedarf aktualisiert.
Aufwandsschätzung
Aus Audit und Matrix entsteht eine belastbare Planung mit Zeitfenster, Reihenfolge und definierten Abbruchkriterien.
Staging: Das Upgrade testen, bevor Kunden es merken
Kein Code-Audit ersetzt einen echten Testlauf. Die Staging-Umgebung ist ein möglichst exakter Klon der Produktivumgebung: gleiche Datenbasis, gleiche Erweiterungen, gleiche Serverkonfiguration. Hier wird die neue PHP-Version zuerst installiert und der komplette Shop unter realistischen Bedingungen geprüft -- ohne dass ein einziger echter Kunde betroffen ist.
Auf Staging läuft das Upgrade zunächst in der Umgebung durch: PHP-Version wechseln, Abhängigkeiten neu auflösen, Cache leeren, Datenbankmigrationen ausführen. Anschließend folgt der eigentliche Test der geschäftskritischen Funktionen. Erst wenn Checkout, Suche, Warenkorb, Kundenkonto und alle Schnittstellen ohne Beanstandung arbeiten, ist die Zielversion freigegeben. Tritt ein Fehler auf, wird er auf Staging behoben -- nicht in der Produktion. Dieser Gate-Ansatz verhindert, dass ein unbemerktes Kompatibilitätsproblem überhaupt erst in den Live-Shop gelangt.
Wichtig ist die Datenaktualität: Ein Staging mit Daten von vor sechs Monaten hat wenig Aussagekraft. Personenbezogene Daten müssen beim Klonen anonymisiert werden, um die DSGVO einzuhalten und versehentliche Test-Mails an echte Kunden zu verhindern. Die Datenbank-Synchronisation und -Pflege ist deshalb eng mit der Upgrade-Planung verzahnt.
# PHP-Version auf Staging prüfen und Upgrade verifizieren
php -v # aktuelle Version anzeigen
composer update --dry-run # Abhängigkeiten gegen Ziel-PHP testen
bin/console cache:clear # Cache nach Versionswechsel leeren
bin/console dal:validate # Datenmodell-Integrität prüfen
# Funktionstests: Checkout, Suche, Warenkorb, API
# Erst nach gruenem Durchlauf -> Go-Live planenErweiterungen und individueller Code als Stolperstein
Erweiterungen sind die häufigste Ursache für fehlgeschlagene PHP-Upgrades. Jedes Plugin, jede Theme-Anpassung und jede Integration enthält eigenen PHP-Code, der mit der Zielversion harmonieren muss. Eine einzige Erweiterung, die eine in der neuen Version entfernte Funktion aufruft, kann den gesamten Shop lahmlegen. Deshalb gehört jede Erweiterung in die Kompatibilitätsmatrix.
Bei Erweiterungen aus der Shopware-Community wird die PHP-Kompatibilität üblicherweise vom Hersteller dokumentiert und gepflegt. Schwieriger sind individuelle Entwicklungen: Eigene Plugins, Template-Overrides und maßgeschneiderte Schnittstellen liegen in der Verantwortung des Betreibers und müssen aktiv gegen die neue PHP-Reihe geprüft und gegebenenfalls angepasst werden. Genau hier zahlt sich professionelle Wartung aus, weil die Wechselwirkungen technisches Detailwissen erfordern.
- Jede installierte Erweiterung gegen die Ziel-PHP-Version prüfen und Status dokumentieren
- Erweiterungen mit verfügbarem Update vor dem PHP-Wechsel aktualisieren
- Individuelle Plugins und Template-Overrides im Quellcode auditieren
- Composer-Abhängigkeiten und Bibliotheken auf Kompatibilität abgleichen
- Inkompatible Erweiterungen ersetzen oder mit Alternativlösung deaktivieren
- Alle Anpassungen zuerst auf Staging verifizieren, nie direkt in Produktion
Go-Live mit Rollback-Absicherung
Ist die Zielversion auf Staging freigegeben, folgt der kontrollierte Go-Live. Auch ein sorgfältig getestetes Upgrade kann in der Produktion Edge Cases zeigen, die im Test nicht auftraten -- eine bestimmte Warenkorbkonstellation, ein spezifischer Zahlungsweg, eine selten genutzte Schnittstelle. Deshalb ist ein getesteter Rollback-Plan Pflichtbestandteil, kein Extra.
Unmittelbar vor dem Versionswechsel werden ein vollständiger Datenbank-Snapshot und ein Dateisystem-Backup erstellt -- nicht das nächtliche Standard-Backup, sondern ein frischer Stand. Das Rollback-Script, das beides wiederherstellt, wurde zuvor auf Staging getestet. Wer seinen Rollback nie geprobt hat, hat im Ernstfall keinen verlässlichen Rollback. Das eigentliche Wartungsfenster für den Versionswechsel ist meist kurz, sollte aber bewusst außerhalb der umsatzstarken Zeiten liegen.
Nach dem Go-Live gilt erhöhte Aufmerksamkeit: Das Monitoring beobachtet Fehlerraten, Antwortzeiten und Conversion in Echtzeit. Klar definierte Schwellenwerte entscheiden über einen Rollback, damit im Ernstfall keine Zeit mit Diskussionen verloren geht. Ein Vorteil überwiegt am Ende den Aufwand: Neuere PHP-Versionen sind deutlich schneller -- ein WordPress-Setup läuft auf PHP 8.3 rund 20 bis 40 Prozent schneller als auf 7.4, ganz ohne Code-Änderung (Kinsta, 2026).
Ein Upgrade ohne getesteten Rollback ist eine Wette. Mit Snapshot, geprobtem Wiederherstellungsweg und Echtzeit-Monitoring wird aus dem Versionswechsel ein Routinevorgang.
PHP-EOL als laufenden Prozess etablieren
Ein einmaliges Upgrade löst das Problem nur vorübergehend, denn der nächste EOL-Termin steht bereits fest. Das deutsche Bundesamt für Sicherheit in der Informationstechnik empfiehlt in seinem IT-Grundschutz, Patches und Aktualisierungen zeitnah nach Veröffentlichung zu bewerten, zu priorisieren und einzuspielen sowie Entscheidungen dazu nachvollziehbar zu dokumentieren (BSI IT-Grundschutz OPS.1.1.3). Für PHP bedeutet das: den Lebenszyklus aktiv verfolgen, statt auf die Hoster-Abschaltung zu warten.
Praktisch lässt sich das in den regulären Wartungsrhythmus integrieren. Die installierte PHP-Version wird dokumentiert, kommende EOL-Termine werden im Kalender hinterlegt, und der nächste Upgrade-Schritt wird geplant, sobald die aktuelle Reihe in die Security-Only-Phase eintritt. So bleibt der Shop dauerhaft auf einer unterstützten Version, und jeder Schritt bleibt klein. Ein strukturierter Wartungsvertrag macht aus dem EOL-Management eine wiederkehrende Routine statt einer Feuerwehraktion.
EOL-Termine früh im Kalender vormerken
Quellen und Studien