Wichtigste Erkenntnisse
- Der erweiterte PHP-Support stellt Sicherheitspatches für PHP-Versionen bereit, deren Lebenszyklus bereits abgelaufen ist (EOL), sodass Sie Ihre Produktionsanwendungen auch ohne erzwungene Migration sicher halten können.
- Der erweiterte Support hat keinen Einfluss auf Ihre PHP-Version oder das Verhalten Ihrer Anwendung. Er schließt bekannte Sicherheitslücken, während Sie die Migration nach Ihrem eigenen Zeitplan durchführen können.
- Ab August 2026 gelten PHP 8.1 und alle darunter liegenden Versionen als EOL und erhalten keine Community-Patches mehr. PHP 8.2, 8.3, 8.4 und 8.5 werden weiterhin unterstützt, haben jedoch jeweils ein festgelegtes Ablaufdatum.
- Der Einsatz von PHP-Versionen, deren Lebensdauer abgelaufen ist (EOL), ohne erweiterten Support bedeutet, dass CVEs nicht gepatcht werden, was zu höheren Risiken bei Audits und der Einhaltung von Vorschriften sowie zu einer vergrößerten Angriffsfläche führt.
Wenn Sie PHP in der Produktion einsetzen, das Ende des Lebenszyklus bringt Sie in eine bekannte, unangenehme Situation: Entweder Sie aktualisieren eine Anwendung, die seit Jahren nicht mehr angefasst wurde, oder Sie verwenden weiterhin eine Laufzeitumgebung, für die keine Sicherheitspatches mehr bereitgestellt werden. Keine der beiden Optionen ist ideal.
Der erweiterte PHP-Support ist der dritte Weg.
In diesem Artikel erfahren Sie, was der erweiterte Support konkret umfasst (und was nicht), welche Compliance- und CVE-Risiken mit einem Verzicht darauf verbunden sind, welche PHP-Versionen ihn derzeit benötigen, wie man ihn gegen ein Upgrade abwägen sollte und welche Anbieter im Jahr 2026 besonders interessant sind.
Was ist der erweiterte PHP-Support?
Der erweiterte PHP-Support ist ein vom Anbieter bereitgestellter Service, bei dem auch nach Einstellung des PHP-Projekts selbst weiterhin Sicherheitspatches für eine PHP-Version bereitgestellt werden. Wenn eine PHP-Version das Ende ihres Lebenszyklus erreicht, zieht das PHP-Projekt einen Schlussstrich: keine CVE-Korrekturen mehr, keine Patches mehr, gar nichts.
Durch den erweiterten Support wird dieses Kapitel wieder aufgeschlagen. Ein Anbieter überwacht neu bekannt gewordene Sicherheitslücken und portiert die Korrekturen rückwirkend in die EOL-Laufzeitumgebung, sodass Ihre Anwendung weiterhin auf einer gepatchten Laufzeitumgebung läuft, während Sie die Migration nach Ihrem eigenen Zeitplan planen können – und nicht nach dem eines anderen.
So funktioniert der PHP-Release-Lebenszyklus
PHP-Versionen folgen nun einem vierjährigen Lebenszyklus: zwei Jahre aktiver Support, gefolgt von zwei Jahren Sicherheits-Support. Diese Regelung geht auf eine im März 2024 vorgenommene Änderung des PHP-Release-Zyklus zurück und gilt für PHP 8.1 und spätere Versionen. Ältere Zweige wie PHP 7.4 und 8.0 behalten den bisherigen dreijährigen Lebenszyklus bei, der aus zwei Jahren aktivem Support und einem Jahr Sicherheits-Support besteht.
| Lebenszyklusphase | Dauer | Was Sie erhalten |
| Aktive Unterstützung | Die ersten zwei Jahre | Fehlerbehebungen, Leistungsoptimierungen, Sicherheitspatches |
| Sicherheitsunterstützung | Die nächsten zwei Jahre | Nur kritische Sicherheitskorrekturen |
| Ende des Lebens | Nach 4 Jahren | Nichts. Keine Patches jeglicher Art. |
Hier ist ein Überblick über die jeweiligen PHP-Versionen:
| PHP-Version | Veröffentlicht | Ende des Lebens | Stand (August 2026) |
| 7.4 | Nov. 2019 | 28. November 2022 | EOL – keine Community-Patches |
| 8.0 | November 2020 | 26. November 2023 | EOL – keine Community-Patches |
| 8.1 | November 2021 | 31. Dezember 2025 | EOL – keine Community-Patches |
| 8.2 | Dezember 2022 | 31. Dezember 2026 | Nur Sicherheitsupdates (EOL Ende 2026) |
| 8.3 | Nov. 2023 | 31. Dezember 2027 | Nur für Sicherheitszwecke |
| 8.4 | Nov. 2024 | 31. Dezember 2028 | Aktiver Support bis zum 31. Dezember 2026, danach nur noch Sicherheitsupdates |
| 8.5 | Nov. 2025 | 31. Dezember 2029 | Aktive Unterstützung |
Wussten Sie schon: Das PHP-Projekt legt nun das Ende des Lebenszyklus (EOL) für alle Versionen auf den 31. Dezember des jeweiligen Jahres fest. PHP 8.1 war die erste Version, die von diesem verlängerten Zyklus profitierte, wobei dessen EOL vom November 2024 auf den 31. Dezember 2025 verschoben wurde.
Was der erweiterte PHP-Support tatsächlich bietet
Der erweiterte Support ist bewusst eng gefasst. Seine Aufgabe besteht darin, eine PHP-Version nach Ablauf der Lebensdauer (EOL) sicher zu halten, nicht darin, sie zu modernisieren, umzugestalten oder um Funktionen zu erweitern. Er stellt die Sicherheitspatches bereit, deren Veröffentlichung die Community eingestellt hat – und zwar in einer Form, die Sie bereitstellen können, ohne die Anwendung zu beeinträchtigen, die auf genau diese Laufzeitumgebung angewiesen ist.
Realitätscheck: Der erweiterte Support ist kein Freifahrtschein, um niemals ein Upgrade durchzuführen. Er verschafft Ihnen Zeit für die Migration, ohne dass eine Notfallsituation entsteht. Betrachten Sie ihn als Startbahn, nicht als Ziel.
Rückwärtsportierte Sicherheitspatches
Der Kernservice ist das Backporting. Wenn eine neue CVE für einen noch unterstützten PHP-Zweig gemeldet wird, analysiert der Anbieter, ob die EOL-Version betroffen ist, und portiert den Fix anschließend zurück in Ihre alte Laufzeitumgebung, ohne deren Verhalten zu verändern. Sie bleiben bei PHP 7.4 oder 8.1, aber die Sicherheitslücke wird geschlossen.
Kompatibilitätstests und unterbrechungsfreie Bereitstellung
Ein zurückportierter Patch muss weiterhin die Stabilität der Anwendung gewährleisten. Zu einer guten erweiterten PHP-Unterstützung gehören Regressionstests gegenüber der EOL-Version, damit der Fix keine Verhaltensänderungen mit sich bringt. Je nach Anbieter und Plattform werden Patches als native Pakete – RPM oder DEB unter Linux – bereitgestellt, die über Ihren vorhandenen Paketmanager installiert werden können; für Windows stehen entsprechende Installationsprogramme zur Verfügung.
Version und Betriebssystemumfang
Jeder Anbieter unterstützt bestimmte PHP-Versionen auf bestimmten Betriebssystemen. Zum Beispiel umfasst der „Endless Lifecycle Support“ (ELS) von TuxCare für PHP umfasst PHP 5.2 bis 8.4, wobei für jeden Zweig, sobald er das EOL erreicht hat – derzeit 5.2 bis 8.1 –, ELS-Sicherheitspatches bereitgestellt werden – und zwar unter Windows und den wichtigsten Linux-Distributionen, darunter AlmaLinux, CentOS, Ubuntu, Debian und Oracle Linux. Wenn Sie an einer EOL-Laufzeitumgebung festhängen, die sich nicht reibungslos migrieren lässt, ist diese Art der vom Anbieter unterstützten Patching-Maßnahmen eine der wenigen Möglichkeiten, die CVE-Sicherheitslücke zu schließen, ohne die Anwendung sofort für eine neuere Laufzeitumgebung überarbeiten zu müssen.
Hinweis: Ein Upgrade von PHP 5.x auf PHP 8.x kann erhebliche Änderungen am Code erfordern, insbesondere bei Anwendungen, die auf entfernte Sprachfunktionen, veraltete APIs oder veraltete Frameworks zurückgreifen.
Sicherheits- und Compliance-Risiken beim Einsatz von PHP-Versionen am Ende ihres Lebenszyklus (EOL) ohne erweiterten Support
Die Website wird geladen, der Bezahlvorgang funktioniert, die Protokolle sehen einwandfrei aus. Doch das Risiko wächst still und leise, da neue CVEs für Ihre Version bekannt werden und nie behoben werden. „Es funktioniert ja noch“ – das ist die Falle.
Eine EOL-Laufzeitumgebung, die heute noch einwandfrei läuft, ist zugleich diejenige mit der längsten Liste an ungepatchten, öffentlich dokumentierten Sicherheitslücken – und genau danach suchen Angreifer.
Nicht behobene CVEs und aktive Ausnutzung
Sobald eine Version das Ende ihres Lebenszyklus (EOL) erreicht hat, werden neu bekannt gewordene Sicherheitslücken, die diese Version betreffen, vom PHP-Projekt auf unbestimmte Zeit nicht mehr behoben. Angreifer können erkennen, für welche Versionen keine Patches mehr bereitgestellt werden, und öffentlich zugängliche Exploits funktionieren weiterhin gegen Systeme, für die nie ein zurückportierter Patch bereitgestellt wurde.
Der Verizon DBIR 2026 ergab, dass die Ausnutzung von Sicherheitslücken mittlerweile der häufigste Erstzugriffsvektor für Sicherheitsvorfälle ist und 31 % der Fälle ausmacht – ein Anstieg gegenüber 20 % im Vorjahresbericht. Es ist das erste Mal in der 19-jährigen Geschichte des Berichts, dass die Ausnutzung von Sicherheitslücken den ersten Platz einnimmt und damit den Missbrauch von Anmeldedaten sowie Phishing übertrifft. Echte PHP-CVE-Einträge verdeutlichen dies: Siehe den Bericht über eine Sicherheitslücke in PHP 7 nach Ablauf der Supportfrist PHP-7-Sicherheitslücke (CVE-2023-0568)sowie CVE-2024-4577, eine CGI-Argument-Injection-Schwachstelle mit einem CVSS-Wert von 9,8, die in den Katalog der „Known Exploited Vulnerabilities“ der CISA aufgenommen wurde und PHP-Installationen unter Windows schwer getroffen hat. Das allgemeine Muster wird in dieser Übersicht über PHP-Sicherheitslückenbehandelt. Ohne einen Backport des Quellcodes ist ein Upgrade in der Regel der einzige zuverlässige Weg, um die zugrunde liegende Schwachstelle zu beseitigen.
Nichteinhaltung der Vorschriften
Sicherheits- und Compliance-Rahmenwerke verlangen von Unternehmen in der Regel, Schwachstellen zu identifizieren, Risiken zu managen und Sicherheitsupdates innerhalb eines festgelegten Zeitrahmens zu installieren. PCI DSS legt explizite Anforderungen an das Patchen und das Schwachstellenmanagement fest, während HIPAA, SOC 2und FedRAMP verfolgen durch Risikoanalysen und Kontrollbewertungen denselben Ansatz. Der Einsatz von Software, für die keine Upstream-Korrekturen mehr bereitgestellt werden, erschwert die Erfüllung dieser Verpflichtungen, es sei denn, Sie verfügen über eine dokumentierte Quelle für zurückportierte Patches und entsprechende Nachweise.
Laut dem IBM-Bericht „Cost of a Data Breach Report 2026“stiegen die weltweiten Durchschnittskosten einer Datenschutzverletzung im Vergleich zum Vorjahr um 12 % auf einen Rekordwert von 4,99 Millionen US-Dollar. Ein erweiterter Support kann die Patch-Protokolle und Zeitpläne für die Behebung bereitstellen, die eine konsequente Schwachstellenbewertung und einen einheitlichen Patch-Prozess belegen. In regulierten Umgebungen kommen darüber hinaus separate Verpflichtungen hinzu – FIPS-Konformität für validierte kryptografische Module –, doch speziell in Bezug auf das Thema Patches lässt sich eine lückenlose Dokumentation weitaus leichter erstellen, wenn die Patches tatsächlich vorhanden sind.
Risiken in der Lieferkette und Abhängigkeiten
PHP läuft selten isoliert. Ihre Anwendung nutzt Composer-Pakete, Erweiterungen und ein zugrunde liegendes Betriebssystem – und eine Sicherheitslücke in einer beliebigen dieser Schichten ist Ihr Problem. Eine PHP-Laufzeitumgebung, deren Support ausgelaufen ist, läuft oft parallel zu einem Betriebssystem am Ende seines Lebenszyklus und veralteten Abhängigkeiten, was die Angriffsfläche vervielfacht.
Für welche PHP-Versionen ist derzeit ein erweiterter Support erforderlich?
Wenn Sie PHP 8.1 oder eine ältere Version verwenden und nicht umgehend aktualisieren können, benötigen Sie eine zuverlässige Quelle für zurückportierte Sicherheitspatches. Für diese Versionen werden ab 2026 keine Sicherheitspatches mehr von der Community bereitgestellt, sodass neu bekannt gewordene Sicherheitslücken, die diese Versionen betreffen, vom PHP-Projekt nicht behoben werden.
PHP 7.4 ist der dringlichste Fall. Diese Version erreichte im November 2022 das Ende der Lebensdauer (EOL), sodass es nun schon fast vier Jahre ohne Community-Patches gibt. Es läuft immer noch in einer großen Anzahl von Produktionsumgebungen, da eine Migration erhebliche Aufwände in Bezug auf Abhängigkeiten, Kompatibilität und Tests mit sich bringen kann. Ähnlich verhält es sich mit PHP 8.0, das Ende 2023 das EOL überschritten hat, sowie PHP 8.1 Ende 2025 Ende 2025.
PHP 8.2 und 8.3 befinden sich im reinen Sicherheitsmodus; es werden zwar weiterhin Patches bereitgestellt, jedoch mit ablaufender Frist. PHP 8.2 läuft am 31. Dezember 2026 aus, PHP 8.3 folgt ein Jahr später. Tragen Sie das EOL-Datum von PHP 8.2 in Ihren Kalender ein: Nach dem 31. Dezember 2026 werden vom PHP-Projekt keine Sicherheitspatches mehr für diesen Zweig bereitgestellt. Eine vollständige Übersicht über die Risiken und Ihre Optionen finden Sie im PHP 8.2 EOL-Leitfaden ausführlich behandelt.
PHP 8.4 und 8.5 sind die beiden Versionszweige, für die derzeit aktiver Support angeboten wird, wobei 8.4 Ende 2026 in den reinen Sicherheits-Support übergeht. Der erweiterte Support richtet sich an Teams, die nicht innerhalb des von ihren Auditoren oder Risikomanagement-Teams geforderten Zeitrahmens von 7.4, 8.0 oder 8.1 umsteigen können.
Erweiterter PHP-Support oder Upgrade: Wie trifft man die richtige Wahl?
Ein Upgrade ist langfristig die richtige Lösung. Ein erweiterter Support ist kurzfristig die richtige Lösung, wenn ein sofortiges Upgrade zu riskant wäre. Die Entscheidung hängt davon ab, wie viel Migrationsaufwand zwischen Ihnen und einer unterstützten Version liegt und wie hoch das Risiko ist, das Sie in der Zwischenzeit eingehen.
Eine gut gewartete Anwendung lässt sich möglicherweise mit geringem Aufwand hinsichtlich Abhängigkeiten und veralteter Funktionen von PHP 8.1 auf eine aktuell unterstützte Version umstellen, wobei der Aufwand jedoch von den verwendeten Frameworks, Erweiterungen und der Testabdeckung abhängt. Die Umstellung einer älteren 7.4-Anwendung mit 200.000 Zeilen unverändertem Code und nicht mehr gepflegten Abhängigkeiten auf PHP 8.4 ist ein richtiges Projekt und keine Sache für einen Nachmittag. Die Kosten einer Unterschätzung dieses Aufwands sind real.
Aus der Praxis: Ein einmaliges Upgrade löst das Lebenszyklusrisiko nicht dauerhaft. Teams, die vor Jahren von 7.4 auf 8.0 umgestiegen sind, die Sache als erledigt betrachtet und nie den nächsten Schritt geplant haben, sitzen nun auf einem weiteren EOL-Zweig. „Wir haben doch schon einmal ein Upgrade durchgeführt“ – so landet man zweimal im EOL.
Entscheide anhand folgender Informationen:
| Szenario | Empfohlene Vorgehensweise |
| Version 8.1, moderne Abhängigkeiten, kompakter Code | Führen Sie jetzt ein Upgrade auf eine Version durch, für die noch aktiver Support angeboten wird, idealerweise PHP 8.4 oder 8.5. |
| Version 7.4 oder 8.0, große Legacy-Anwendung, keine Testabdeckung | Verlängerter Support, anschließend schrittweise Migration |
| Feste Prüfungsfrist, Migration noch nicht abgeschlossen | Erweiterter Support zur Gewährleistung der Compliance während der Migration |
| Eine App eines Drittanbieters, die der Anbieter nicht aktualisiert hat | Verlängerter Support, bis der Hersteller eine Korrektur bereitstellt |
Die 3 besten Anbieter von erweitertem PHP-Support
Eine Handvoll Anbieter portieren Sicherheitskorrekturen auf PHP-Versionen, deren Lebenszyklus bereits beendet ist. Sie unterscheiden sich hinsichtlich der abgedeckten Versionen, der Art der Bereitstellung der Patches und der Compliance-Dokumentation, die sie Ihnen zur Verfügung stellen. Hier sind drei Anbieter, die einen Vergleich wert sind. Die unten aufgeführten Abdeckungslisten spiegeln die von den jeweiligen Anbietern im August 2026 veröffentlichten Informationen wider; erkundigen Sie sich vor dem Kauf beim Anbieter nach dem aktuellen Umfang.
TuxCare
Der „Endless Lifecycle Support“ von TuxCare für PHP umfasst PHP 5.2 bis 8.4 aus einem einzigen Repository, wobei für jeden Zweig, sobald er das EOL erreicht, ELS-Sicherheitspatches angewendet werden – derzeit 5.2 bis 8.1, wobei 8.2, 8.3 und 8.4 folgen werden, sobald ihre EOL-Termine eintreten. Die Pakete werden vom Anbieter für Windows und die wichtigsten Linux-Distributionen erstellt und mit Sicherheitspatches versehen, vor der Veröffentlichung Regressionstests unterzogen und über Ihren bestehenden Paketmanager installiert, ohne dass ein Wechsel der Laufzeitumgebung oder eine Neukompilierung Ihrer Anwendung erforderlich ist.
Für Teams, die mehrere PHP-Websites über cPanel verwalten, lässt sich das PHP ELS von TuxCare in unterstützten cPanel-Umgebungen in den PHP Selector integrieren. So können Sie die PHP-Versionen für jede Website einzeln über die Verwaltungsoberfläche festlegen, ohne auf die Befehlszeile zurückgreifen zu müssen.
Zend von Perforce
Zend bietet seit Jahren kommerziellen Support für PHP an und stellt Langzeit-Support-Laufzeitumgebungen für EOL-Versionen bereit, die von einem Anbieter mit langjähriger Erfahrung im PHP-Ökosystem unterstützt werden. Der Support ist fokussiert: Zend listet derzeit PHP 7.2, 7.3, 7.4 und 8.1 im Rahmen seines PHP-LTS-Angebots auf. Dies ist eine glaubwürdige Option für Teams, die bereits auf Zend-Tools oder Laminas standardisiert sind.
HeroDevs
HeroDevs bietet im Rahmen einer Partnerschaft mit Zend by Perforce langfristigen Support für PHP an und kombiniert dabei ZendPHP-Laufzeitumgebungen mit seinem eigenen „Never-Ending Support“-Abonnement, SLAs und Compliance-Dokumentation. Der Support umfasst PHP 7.2, 7.3, 7.4, 8.0, 8.1 und 8.2 und wird als native Pakete für alle gängigen Linux-Distributionen und Windows bereitgestellt.
PHP-Patches nach Ablauf der Supportfrist – Sicherheitsrisiken vermeiden und Compliance gewährleisten
Das Ende des Supports für PHP wird nicht angekündigt. Die Plattform verarbeitet weiterhin Datenverkehr, bis ein Angreifer eine öffentlich dokumentierte Sicherheitslücke ausnutzt, für die in Ihrem Zweig nie ein Patch bereitgestellt wurde. Der erweiterte PHP-Support schließt diese Lücke: Sie bleiben bei der Laufzeitumgebung, auf die Ihre Anwendung angewiesen ist, betroffene Sicherheitslücken erhalten rückportierte Korrekturen, und Sie migrieren, wenn es sicher ist – und nicht erst, wenn Sie dazu gezwungen sind.
Wenn Sie PHP 7.4, 8.0 oder 8.1 verwenden und ein sofortiges Upgrade nicht praktikabel ist, sichern Sie die bestehende Laufzeitumgebung mit zurückportierten Patches ab, während Sie die Migration planen. Der „Endless Lifecycle Support“ (ELS) von TuxCare deckt derzeit alle EOL-Zweige von 5.2 bis 8.1 ab und ist bestrebt, diesen Support auf 8.2, 8.3 und 8.4 auszuweiten, sobald die jeweiligen Versionen ihr EOL-Datum erreichen.
FAQs
Nein. Im Rahmen des erweiterten Supports werden Sicherheitspatches in Ihre bestehende Version zurückportiert. Ihre PHP-Version bleibt unverändert und das erwartete Verhalten bleibt erhalten, während für die betroffenen Sicherheitslücken zurückportierte Korrekturen bereitgestellt werden. Die Anwendung, die auf dieser Laufzeitumgebung basiert, kann ohne Versions-Upgrade weiterlaufen.
„PHP Extended Support Level 1“ ist eher eine Abrechnungsbezeichnung des Hosting-Anbieters als eine standardmäßige PHP-Supportstufe. Bei den GoDaddy-Tarifen „Web Hosting (cPanel)“ und „Web Hosting Plus“ ist der PHP Extended Support ein kostenpflichtiges Add-on – bereitgestellt im Rahmen einer Partnerschaft mit CloudLinux –, das Sicherheitspatches für Websites bereitstellt, auf denen noch eine PHP-Version mit abgelaufenem Support (EOL) läuft, und bei der Verlängerung als separate Position aufgeführt wird. Informieren Sie sich in der Dokumentation Ihres Hosting-Anbieters über den genauen Umfang und die Preise Ihres Tarifs.
Ja. PHP 7.4 hat im November 2022 das Ende seines Lebenszyklus erreicht, doch Anbieter wie TuxCare stellen im Rahmen des erweiterten Lebenszyklus-Supports weiterhin Sicherheitspatches dafür bereit. Da 7.4 seit 2022 nicht mehr unterstützt wird, bleibt es einer der wichtigsten Anwendungsfälle für den erweiterten Support für Unternehmen, die ihre Migrationen noch nicht abgeschlossen haben.
Die Zeiträume für die Bereitstellung von Patches variieren je nach Anbieter, ebenso wie der Umfang. Achten Sie vor der Unterzeichnung auf drei Dinge: einen veröffentlichten Schweregrad-Schwellenwert (die meisten Anbieter verpflichten sich, CVEs mit hohem und kritischem Schweregrad zu beheben – in der Regel CVSS 7.0 und höher – und behandeln Probleme mit mittlerem Schweregrad von Fall zu Fall), eine festgelegte Zielbearbeitungszeit für Schwachstellen mit hohem Schweregrad sowie einen öffentlichen CVE-Tracker, damit Sie den Status jeder einzelnen CVE selbst überprüfen können, anstatt sich blind auf das SLA zu verlassen.
Es kann hilfreich sein. Auditoren verlangen Nachweise dafür, dass Ihre Software auf dem neuesten Stand ist und dass ein wiederholbarer Patch-Prozess vorhanden ist. Der erweiterte Support liefert sowohl die Patches als auch die entsprechenden Nachweise. Er allein garantiert jedoch weder die Einhaltung der PCI-DSS-Vorgaben noch die SOC-2-Konformität oder ein erfolgreiches Audit – dies hängt von Ihrem gesamten Kontrollumfeld ab.
Das hängt davon ab, wo man ansetzt. Bei einer großen Legacy-Anwendung mit veralteten Abhängigkeiten ist ein erweiterter Support kurzfristig in der Regel deutlich kostengünstiger als eine Notfallmigration. Bei einer kleinen Anwendung, die ein oder zwei Versionen hinterherhinkt, ist ein direktes Upgrade oft die sinnvollere Investition.




