Ende der Unterstützung für PHP 8.3: Wichtige Termine, Risiken und nächste Schritte

Wichtigste Erkenntnisse

• PHP 8.3 erreicht am 31. Dezember 2027 das Ende seiner Lebensdauer; danach erhält es keine Sicherheitsupdates und keinen offiziellen Support mehr.
• Wenn Sie PHP 8.3 nach Ablauf der Supportfrist weiterverwenden, setzen Sie Ihre Anwendungen ungepatchten Sicherheitslücken und einem wachsenden Sicherheitsrisiko aus.
• Ein Upgrade auf eine neuere PHP-Version ist der sicherste Weg, doch Altcode und Abhängigkeiten verlangsamen Migrationen oft.
• Der „Endless Lifecycle Support“ (ELS) von TuxCare sorgt dafür, dass PHP 8.3 auch nach Ablauf der Supportfrist weiterhin mit Patches versorgt wird, während Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen können.

PHP 8.3 erreicht am 31. Dezember 2027 das Ende seines Lebenszyklus. Nach diesem Datum stellt das PHP-Projekt die Veröffentlichung von Sicherheitspatches für diese Version ein. Jede nach dem EOL für PHP 8.3 bekannt gewordene CVE wird zu einer dauerhaften, nicht behebbaren Sicherheitslücke auf jedem Server, auf dem diese Version noch läuft – und das ist keine hypothetische Annahme. Genau in der Zeitspanne zwischen der Erkenntnis, dass ein Upgrade erforderlich ist, und dessen tatsächlicher Durchführung geraten Unternehmen in Schwierigkeiten.

In diesem Beitrag erfahren Sie, was das Ende des Supports für PHP 8.3 in der Praxis bedeutet, was konkret mit Ihrer Produktionsumgebung geschieht, sobald der Support endet, und welche Möglichkeiten es gibt, Ihre PHP-Infrastruktur sicher und konform zu halten.

Den Support-Lebenszyklus von PHP verstehen

Im März 2024 verlängerte das PHP-Projekt seinen Release-Zyklus von drei auf vier Jahre. Jeder Zweig erhält nun zwei Jahre aktiven Support, gefolgt von zwei Jahren reinen Sicherheits-Supports, bevor er das Ende seines Lebenszyklus erreicht.

• Aktiver Support: In den ersten zwei Jahren nach der Veröffentlichung stellt das PHP-Projekt Bugfixes, Sicherheitspatches und allgemeine Wartungsupdates bereit. Dies ist ein umfassender Support.
• Support ausschließlich für Sicherheitszwecke: Nach Ablauf des aktiven Supports erhält die Version weitere zwei Jahre lang eingeschränkten Support – es werden nur bestätigte, kritische Sicherheitslücken behoben. Sonst nichts.
• Ende des Supportzyklus: Keine Sicherheitskorrekturen jeglicher Art. Die Version wird vom Hersteller nicht mehr unterstützt.

Dieses Lebenszyklusmodell prägt in gleichem Maße die Websicherheit, die Compliance-Situation und die Wartungsplanung. Ein häufig begangener Fehler ist es, das EOL als ein Problem der Zukunft zu betrachten – wenn das Datum erst einmal gekommen ist, hinkt man bereits hinterher. Dieselbe Dynamik zeigt sich im gesamten Stack; es lohnt sich daher, zu verstehen, wie sie sich auch auf Situationen auswirkt, in denen das Betriebssystem das Ende seines Lebenszyklus erreicht.

Ende der Unterstützung für PHP 8.3: Wichtige Termine und zu beachtende Punkte

PHP 8.3 wurde am 23. November 2023 veröffentlicht. Hier ist der vollständige Zeitplan für den Support:

Der aktive Support endete am 31. Dezember 2025 – das bedeutet, dass PHP 8.3 sich bereits in der Phase befindet, in der nur noch Sicherheitsupdates bereitgestellt werden. Wenn Sie diese Version derzeit nutzen, befinden Sie sich bereits im Bereich mit eingeschränktem Support, und die Uhr bis zum vollständigen Ende des Supports tickt.

Die Dringlichkeit in diesem Fall spiegelt die Situation wider, mit der Teams beim Ende des Supports für PHP 7.4, PHP 8.2 und PHP 8.1 konfrontiert waren – gleiche Dynamik, andere Versionsnummer. Die allgemeine Situation beim Ende des Supports für PHP über alle Versionen hinweg macht eines deutlich: Es handelt sich hierbei nicht um eine einmalige Situation, die es zu überstehen gilt, sondern um ein wiederkehrendes Betriebsmuster, für das es sich lohnt, einen Prozess zu entwickeln.

Auslöser für den Plan: Wenn Ihr Upgrade-Zeitplan realistisch gesehen bis Dezember 2027 abgeschlossen werden kann, sollten Sie jetzt damit beginnen. Ist dies nicht der Fall – sei es aufgrund von Abhängigkeiten von Alt-Systemen, der Komplexität der Anwendungen oder Ressourcenengpässen –, lesen Sie den Abschnitt „Lösungen“, bevor Sie Entscheidungen treffen.

Was passiert, wenn PHP 8.3 das Ende seines Lebenszyklus erreicht?

Nach Ablauf der Supportfrist wird das PHP-Projekt die Version 8.3 endgültig einstellen. Keine Patches, keine Sicherheitshinweise, keine Backports. Wird Ende 2027 eine kritische Sicherheitslücke entdeckt, die die Ausführung von Remote-Code ermöglicht und PHP 8.3 betrifft? Dann müssen Sie dieses Problem ohne jegliche Unterstützung seitens der Entwickler selbst lösen. So sieht das in der Praxis aus.

Unbehobene Sicherheitslücken häufen sich, ohne dass eine Lösung in Sicht ist

Auch nach dem Ende des Supports werden weiterhin PHP-Sicherheitslücken entdeckt. Forscher finden sie nach wie vor und veröffentlichen sie – sie werden lediglich in Version 8.3 nicht mehr behoben. Das Sicherheitsrisiko Ihrer Umgebung nimmt mit der Zeit zu, ohne dass es einen Mechanismus gibt, um es zu verringern.

In der Praxis läuft das folgendermaßen ab: Ihr Schwachstellenscanner stuft PHP 8.3 als EOL ein und beginnt, ungepatchte CVEs damit zu verknüpfen. Anfangs ist die Liste noch kurz. Nach sechs Monaten ist sie länger. Nach einem Jahr ist für einige dieser CVEs öffentlicher Exploit-Code in automatisierte Scan-Tools integriert – wodurch die Ausnutzung von gezielten Angriffen zu opportunistischen Angriffen wechselt. Angreifer, die breit angelegte PHP-Exploit-Scans durchführen, müssen nichts über Ihre spezifische Anwendung wissen.

Ein mittelständisches SaaS-Unternehmen, das ein Jahr nach dem EOL-Datum noch immer eine veraltete PHP 8.3-Codebasis betreibt, ist kein hypothetisches Risikoszenario. Es handelt sich um einen Server, der in Scan-Ergebnissen mit bekannten, ungepatchten Schwachstellen auftaucht, für die keine Lösung verfügbar ist. Ihr Sicherheitsteam verbringt Zeit damit, Probleme zu priorisieren, die es nicht beheben kann. Ihr Risikoregister enthält einen dauerhaft offenen Eintrag. Das sind die tatsächlichen Betriebskosten.

Compliance-Rahmenwerke werden dies melden

PCI DSS, SOC 2, HIPAA, ISO 27001 – alle diese Standards verlangen, dass Software vor bekannten Sicherheitslücken geschützt wird. Der Einsatz von PHP-Versionen, deren Lebenszyklus abgelaufen ist (EOL), stellt nach den meisten dieser Rahmenwerke einen direkten, nachweisbaren Verstoß dar, und Tools zur Automatisierung der Compliance-Prüfung werden dies aufdecken, ohne dass jemand danach suchen muss. Bei Ihrem nächsten Sicherheitsaudit wird der Prüfer Sie nach Ihrem Plan zur Behebung dieser Mängel fragen.

„Wir sind uns dessen bewusst und arbeiten daran“ – das gilt nur für eine gewisse Zeit. In regulierten Branchen kann eine Software, deren Lebenszyklus sich dem Ende zuneigt, die Erneuerung von Compliance-Zertifizierungen verzögern und in Sicherheitsfragebögen von Anbietern zur Sprache kommen. Für Unternehmen, die an Firmenkunden verkaufen, die SOC-2- oder PCI-DSS-Dokumente verlangen, kann dies zu einem Hindernis für den Geschäftsabschluss werden.

In unserem ausführlichen Leitfaden zum erweiterten PHP-Support können Sie außerdem nachlesen, wie Anbieter mit Sicherheitspatches und Audit-Anforderungen umgehen.

Fehler und Regressionen gehen auf dein Konto

Nach dem EOL musst du jedes Problem, auf das du in PHP 8.3 stößt, ohne Hilfe vom Upstream selbst beheben. Ein fehlerhaftes Verhalten in einem Randfall, das in einer aktiven Version behoben worden wäre? Es wird keine Korrektur geben. Eine Leistungseinbuße aufgrund einer Bibliothek, die schlecht mit der Laufzeitumgebung zusammenarbeitet? Finde die Ursache selbst heraus.

Dies summiert sich im Laufe der Zeit. Es werden Entwicklungsstunden für die Fehlerbehebung aufgewendet, die im Upstream-Code mit einem einzigen Patch hätten behoben werden können. In der Codebasis häufen sich Workarounds an. Die Diskrepanz zwischen dem Verhalten von PHP 8.3 und dem dokumentierten PHP-Verhalten vergrößert sich, da Patches in neueren Versionen ohne Backport implementiert werden. 18 bis 24 Monate nach dem EOL macht dieser Wartungsaufwand eine spätere Migration deutlich schwieriger und teurer, als dies zu einem früheren Zeitpunkt der Fall gewesen wäre.

Warum das Upgrade auf PHP 8.3 komplexer ist, als es scheint

Ein Upgrade auf die nächste unterstützte Version ist die richtige Entscheidung – daran besteht kein Zweifel. Was jedoch direkt angesprochen werden sollte, ist die Frage, warum so viele Teams überhaupt mit einer PHP-Version arbeiten, deren Lebenszyklus bereits abgelaufen ist, denn das liegt selten an Faulheit. Die Hindernisse sind real.

Kompatibilität von Abhängigkeiten

Jede nicht ganz einfache PHP-Anwendung verfügt über eine Abhängigkeitskette: Frameworks, Bibliotheken, CMS-Plugins, interne Pakete. Nicht alle davon werden auf dem aktuellen Stand der PHP-Versionen gehalten. Je weiter man sich von einem modernen, gut gepflegten Framework entfernt, desto problematischer wird dies.

Eine Laravel-Anwendung mit First-Party-Abhängigkeiten lässt sich wahrscheinlich problemlos migrieren. Eine 200.000 Zeilen umfassende, benutzerdefinierte PHP-Codebasis, die auf einem Framework basiert, das seit 2019 nicht mehr gepflegt wird – oder ein WordPress-Stack mit 40 Plugins unterschiedlicher Pflegequalität – erfordert eine umfassende Abhängigkeitsprüfung, bevor man den Umfang der Migration überhaupt abschätzen kann. Und diese Prüfung deckt zuverlässig Hindernisse auf, die zu Beginn nicht offensichtlich waren.

In unserem ausführlichen Leitfaden zur Laravel-Sicherheit können Sie sich außerdem über bewährte Verfahren zur Absicherung von PHP-Frameworks informieren.

Das Muster ist immer dasselbe: Teams führen zunächst eine Kompatibilitätsprüfung durch, finden und beheben die offensichtlichen Probleme, führen eine weitere Prüfung durch, entdecken weitere Probleme und stellen fest, dass die Migration ein dreimonatiges Projekt ist, von dem sie ursprünglich dachten, es würde nur eine Woche dauern. Veraltete Abhängigkeiten und eine Laufzeitumgebung, deren Lebensdauer abgelaufen ist, bestehen nicht nur nebeneinander – sie verstärken auch gegenseitig ihre Risiken.

Änderungen am Anwendungscode erforderlich

Mit PHP 8.4 wurden veraltete Funktionen und Verhaltensänderungen eingeführt, die dazu führen, dass Code, der unter 8.3 einwandfrei lief, nun nicht mehr funktioniert – implizit nullfähige Parameter, bestimmte Verhaltensweisen von Array-Funktionen und einige interne API-Schnittstellen wurden so geändert, dass explizite Code-Aktualisierungen erforderlich sind und nicht nur ein Versionswechsel zur Laufzeit.

Für ein Team mit einer modernen Codebasis, aktiver Testabdeckung und statischer Analyse, die bereits in die CI integriert ist, ist dies machbar: Rector ausführen, die aufgezeigten Fehler beheben, anhand der Testsuite validieren, bereitstellen. Für ein Team mit einer veralteten Codebasis, geringer Testabdeckung, fehlenden Tools zur statischen Analyse und einer kleinen Entwicklerorganisation, die versucht, Produktfunktionen gleichzeitig auf den Markt zu bringen, stellt dies einen echten Ressourcenkonflikt dar. Was man nicht ausreichend testen kann, lässt sich nicht sicher migrieren.

Selbst nachdem Sie alle gemeldeten Veralterungen behoben haben, müssen Sie sicher sein, dass sich das Verhalten in der Produktion nicht unbemerkt geändert hat. Diese Sicherheit erfordert Tests. Fehlt diese Abdeckung, wird aus einer geplanten Migration ein Vorfall.

Zeitliche Risiken und operationelle Risiken

Upgrades der PHP-Version in der Produktionsumgebung bergen ein echtes Risiko. Selbst gründlich getestete Migrationen haben zu unerwartetem Verhalten während der Laufzeit geführt – Grenzfälle, die in der Staging-Umgebung nicht aufgetreten sind, Probleme bei Pfaden mit hohem Datenaufkommen sowie Integrationen von Drittanbietern, die sich unter einer neuen Laufzeitversion anders verhalten.

Ein 40-köpfiges SaaS-Team, das sich mitten in einem großen Feature-Release-Zyklus befindet, kann dieses Risiko nicht ohne Weiteres auffangen. EOL-Fristen lassen sich nicht mit Sprint-Zyklen oder vierteljährlichen Geschäftszielen vereinbaren. Die Folge ist eine Verschiebung – „wir machen das im nächsten Quartal“ –, bis die Frist so knapp ist, dass unter Druck eine überstürzte Migration erzwungen wird. Das ist der denkbar schlechteste Zeitpunkt für ein Versions-Upgrade.

Wichtige Lösungen für den Umgang mit dem Ende des Supports für PHP 8.3

Es gibt keine allgemeingültige Antwort. Der richtige Weg hängt von der Komplexität Ihrer Codebasis, der Kapazität Ihres Teams, Ihrer Risikobereitschaft und davon ab, wie viel Zeit Ihnen bis Dezember 2027 noch bleibt. Hier sind Ihre drei realistischen Optionen, geordnet von der dringendsten bis zur langfristigsten.

Entscheidungsrahmen:

• Wenn Ihr Team das vollständige Upgrade noch vor dem Ende der Lebensdauer (EOL) abschließen kann, fahren Sie direkt mit Lösung Nr. 2 fort.
• Falls Ihr Zeitplan ungewiss ist oder über das EOL hinausgeht, beginnen Sie mit Lösung Nr. 1 und führen Sie parallel dazu Lösung Nr. 2 durch.
• Falls Ihre Anwendung strukturelle Altlasten aufweist, die eine Migration auf PHP 8.4 fast so kostspielig machen wie eine Neuprogrammierung, sollten Sie Lösung Nr. 3 prüfen, bevor Sie Ressourcen bereitstellen.

Lösung 1: Nutzen Sie den lebenslangen Support

Der „Endless Lifecycle Support“ (ELS) von TuxCare für PHP bietet zurückportierte Sicherheitspatches für PHP 8.3 auch nach dem offiziellen EOL-Datum. So bleibt Ihre Umgebung auf dem neuesten Stand und Ihre CVE-Liste überschaubar, während Sie die Migration nach Ihrem eigenen Zeitplan durchführen können – ohne unter Termindruck ein überstürztes Upgrade vornehmen zu müssen. Der PHP ELS von TuxCare deckt eine umfangreiche Liste von PHP-Versionen ab, deren Lebenszyklus sowohl unter Windows- als auch unter Linux-Systemen abgelaufen ist: 5.2, 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3 und 8.4 (sobald auch diese das Ende ihrer Lebensdauer erreicht).

Dies ist die richtige Wahl, wenn Ihr Upgrade realistischerweise nicht vor Dezember 2027 abgeschlossen sein wird, wenn Sie über eine komplexe Codebasis verfügen, die eine sorgfältige, schrittweise Migration erfordert, oder wenn Sie während der Übergangsphase ein tragfähiges Sicherheits- und Compliance-Niveau aufrechterhalten müssen.

ELS ist keine dauerhafte Lösung – irgendwann muss man dennoch migrieren. Aber es schließt die Lücke, in der man andernfalls ungesicherte PHP-Versionen in der Produktion laufen lassen würde, mit einer wachsenden Liste unbehobener CVEs und ohne Möglichkeit zur Behebung.

Besuchen Sie unseren CVE-Tracker, um sich über Sicherheitslücken in PHP-Versionen zu informieren, deren Support ausgelaufen ist, und prüfen Sie, ob über den ELS von TuxCare Patches verfügbar sind.

Lösung 2: Aktualisieren Sie auf PHP 8.4 oder PHP 8.5

PHP 8.5 ist eine solide Upgrade-Option, für die bis Dezember 2029 aktiver Support angeboten wird. PHP 8.4, der nächste Release-Zweig direkt nach Version 8.3, wird bis Dezember 2028 unterstützt. Beide bieten Ihnen vollen Upstream-Support – Sicherheitsupdates, Fehlerbehebungen und Wartung –, den PHP 8.3 nicht mehr bietet.

Konkrete Schritte:

• ausführen. php -l in Ihrem gesamten Code, um Syntaxfehler zu erkennen
• Verwenden Sie Rector, um veraltete Muster nach Möglichkeit automatisch zu beheben
• Überprüfen Sie Ihren Abhängigkeitsbaum auf blockierende Kompatibilitätsprobleme
• Führen Sie Ihre gesamte Testsuite vor der Einführung in der Produktion auf der neuen Laufzeitumgebung aus
• Führen Sie die Migration schrittweise durch, wo es möglich ist – es muss nicht alles auf einmal geschehen

Fangen Sie jetzt damit an, falls Sie es noch nicht getan haben. Die Teams, die es richtig machen, sind diejenigen, die mit genügend Zeitreserven begonnen haben, um methodisch vorgehen zu können. Diejenigen, die auf die Nase fallen, sind diejenigen, die im dritten Quartal 2027 erst anfangen und versuchen, unter Termindruck zu arbeiten, ohne Spielraum für Unvorhergesehenes zu haben.

Lösung 3: Eine vollständige Neuprogrammierung oder eine Framework-Migration in Betracht ziehen

Wenn ein Upgrade auf PHP 8.4 ohnehin umfangreiche Neuprogrammierungen erfordern würde, lohnt es sich, einen ehrlichen Kostenvergleich anzustellen: eine gezielte PHP-Migration gegenüber einer umfassenderen architektonischen Investition in eine andere Laufzeitumgebung. Das ist nicht für jedes Team die richtige Entscheidung – doch bei Anwendungen, bei denen das Problem mit der PHP-Version nur ein Symptom tiefer liegender technischer Schulden ist, kann das EOL-Datum der Auslöser sein, der schließlich das höhere Projektbudget rechtfertigt.

Lassen Sie sich nicht durch die Dringlichkeit des EOL zu einer kostspieligen Migration drängen, bei der der damit verbundene Wartungsaufwand unverändert bleibt. Wenn Sie bereits viel Entwicklungszeit in dieses Projekt investieren, sollten Sie sicherstellen, dass Sie sich damit einen Vorteil für die Zukunft verschaffen und nicht nur Zeit gewinnen.

Sorgen Sie mit TuxCare für die Sicherheit Ihrer Systeme nach dem Ende des Supports für PHP 8.3

Das Ende des Supports für PHP 8.3 ist ein Termin, den man in die Planung einbeziehen kann. In Schwierigkeiten geraten jene Teams, die dies als ein zukünftiges Problem anderer betrachten, bis es zu ihrem aktuellen Notfall wird.

Wenn Sie mehr Zeit benötigen, um die Migration ordnungsgemäß durchzuführen, sorgt der „Endless Lifecycle Support“ von TuxCare dafür, dass PHP 8.3 stets auf dem neuesten Stand und auditfähig bleibt, während Sie das Upgrade nach einem realistischen Zeitplan durchführen. Und wenn Sie EOL-Risiken in mehreren Teilen Ihres Stacks verwalten, deckt der ELS von TuxCare eine breite Palette von Sprachen und Bibliotheken ab – darunter .NET, Node.js, Angular, React und Vue – für Teams, die mit dem gleichen Problem über verschiedene Frameworks hinweg konfrontiert sind.

FAQs

Zusammenfassung

Artikel Name

Ende der Unterstützung für PHP 8.3: Wichtige Termine, Risiken und nächste Schritte

Beschreibung

Informieren Sie sich über die End-of-Life-Termine für PHP 8.3, den Zeitplan für den Support, die damit verbundenen Risiken und die Maßnahmen, die Sie ergreifen sollten, um auch nach dem Ende des Supports für PHP 8.3 die Sicherheit Ihrer Systeme zu gewährleisten.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers