Kurz gesagt: Für PHP 8.1 und älter gibt es vom PHP-Projekt keine offiziellen Updates mehr. Langzeitsupport, auch Extended Support genannt, kommt von Linux-Distributionen, Drittanbieter-Repositories oder kommerziellen Diensten wie TuxCare ELS oder Zend/HeroDevs. Er kann die Zeit bis zum Upgrade überbrücken, wenn der Anbieter die Abdeckung für Ihre Version schriftlich bestätigt. Er ersetzt aber weder das Upgrade noch die Pflege von CMS und eigenem Code.
Warum die Frage gerade jetzt auf den Tisch kommt
Am 21. Oktober 2026 erschienen die PHP2Shell-Korrekturen nur für die unterstützten Zweige 8.5, 8.4, 8.3 und 8.2. Für 7.4, 8.0 und 8.1 hat das PHP-Projekt lediglich minimale Quell-Backports bereitgestellt, also Korrekturen im Quellcode ohne fertiges Release. Laut Fachpresse sind nahezu alle Versionen bis PHP 5.4 betroffen.
Wie groß der Bestand ist, zeigt eine Auswertung von CybelAngel: Rund 2,24 Millionen aus dem Internet erreichbare PHP-Hosts, davon laut CybelAngel 59 Prozent auf Versionen ohne kommenden offiziellen Fix. Für viele Unternehmen ist die Frage nach Langzeitsupport damit keine theoretische mehr. Und sie wird größer: PHP 8.2 erreicht am 31.12.2026 das Ende der Unterstützung.
Was ein Altsystem jetzt sofort braucht, beschreibt PHP 8.1 und älter: Was jetzt gilt. Dieser Beitrag hilft bei der mittelfristigen Frage: Welcher Weg trägt bis zum Upgrade, und was muss er leisten?
PHP Extended Support: die Wege im Überblick
| Weg | Was er liefert | Grenzen |
|---|---|---|
| Langzeitpflege der Distribution | Backports in den Paketen, solange die Distributionsversion unterstützt wird | nur für die PHP-Version, die diese Distribution mitbringt |
| Drittanbieter-Repository | z. B. sury.org, laut Berichten mit Builds von 5.6 bis 8.5 | nicht das Sicherheitsarchiv der Distribution, Vertrauensfrage |
| Kommerzieller Langzeitsupport | gepatchte Pakete für ausgelaufene Versionen, z. B. TuxCare ELS, Zend/HeroDevs | Abdeckung je Version und CVE bestätigen lassen, laufende Kosten |
| Selbstbau aus Quell-Backports | eigene Builds aus den Korrekturen des PHP-Projekts | aufwendig, bei jeder Lücke erneut nötig |
Zu den kommerziellen Angeboten: TuxCare beschreibt auf seiner Website CVE-Korrekturen für ausgelaufene Versionen von PHP 5.2 bis 8.x, ausgeliefert über die vorhandene Paketverwaltung, für Windows und gängige Linux-Distributionen. Ein Hinweis auf derselben Seite meldet PHP2Shell-Korrekturen für ausgelaufene PHP-Versionen. Laut cPanel-Dokumentation sagt TuxCare für Lücken ab CVSS 7 Korrekturen binnen 14 Tagen nach Veröffentlichung zu; auf cPanel-Servern werden dafür Domains von ea-php auf alt-php umgestellt. Zu Zend/HeroDevs lag uns keine Aussage zur PHP2Shell-Abdeckung vor.
Hinweise zum Drittanbieter-Weg gibt der Beitrag Das sury.org-Repository.
Was Sie vom Anbieter schriftlich brauchen
Langzeitsupport ist eine Vertrauensleistung. Sie kaufen das Versprechen, dass künftige Lücken geschlossen werden. Lassen Sie sich deshalb vor der Entscheidung schriftlich beantworten:
- Welche PHP-Versionen, Betriebssysteme und Paketnamen sind genau abgedeckt?
- Sind CVE-2026-109618 und CVE-2026-109619 für Ihre Version geschlossen, mit welchem Paketstand und seit wann?
- Wie wird mit CVE-2026-115560 und künftigen Folgemeldungen umgegangen?
- Sind die von Ihnen genutzten Erweiterungen enthalten oder nur der PHP-Kern?
- Wie prüfen Sie selbst nach, dass ein Patch eingespielt ist, etwa über den Paket-Changelog?
- Wie lange läuft die Abdeckung für Ihre Version, und wie wird ein Ende angekündigt?
- Was passiert mit den installierten Paketen, wenn der Vertrag endet?
Antworten, die nur allgemein auf „alle Sicherheitslücken“ verweisen, genügen nicht. Für Prüfer, Versicherer und Ihre eigene Dokumentation zählt die konkrete Zuordnung von Version, Paket und CVE.
Die Grenzen: Was Langzeitsupport nicht löst
Langzeitsupport hält die PHP-Laufzeit auf Stand. Alles darüber bleibt Ihre Aufgabe. Und gerade dort liegt bei Altsystemen meist das größere Problem.
- Die Anwendung veraltet weiter: Ein CMS oder Shop, der PHP 8.1 braucht, ist oft selbst nicht mehr in der aktuellen Version im Einsatz.
- Bibliotheken und Erweiterungen: Composer-Pakete und Plugins erhalten für alte PHP-Versionen häufig keine Updates mehr.
- Kein Ersatz für Neustart und Prüfung: Auch gepatchte Pakete wirken erst nach dem Neustart aller PHP-Prozesse, und sie entfernen keine Schadsoftware, die vorher eingeschleust wurde.
- Technische Schulden wachsen: Je länger die Brücke, desto größer der Sprung bei der späteren Migration.
- Nachweise werden aufwendiger: Prüfer, Kunden und Versicherer fragen zunehmend nach dem Patch-Stand. Eine ausgelaufene PHP-Version mit Drittanbieter-Patches lässt sich belegen, verlangt aber mehr Erklärung als eine unterstützte Version.
Wann ist Langzeitsupport trotzdem die richtige Wahl? Typisch sind drei Lagen: eine Fachanwendung, deren Hersteller neuere PHP-Versionen noch nicht freigibt; ein Altsystem, dessen Ablösung bereits beschlossen ist und nur noch wenige Monate laufen soll; oder eine große Codebasis, deren Umstellung sorgfältig geplant werden muss. In allen drei Fällen kauft Langzeitsupport Zeit für eine geordnete Lösung. Er ist keine Lösung für Systeme, um die sich niemand mehr kümmern will.
Lief ein Altsystem zwischen dem 17. und dem 21. Oktober ungeschützt im Internet, klären Sie erst, ob es kompromittiert ist. Langzeitsupport für ein bereits befallenes System schützt nichts.
Ein Ausstiegsplan gehört dazu
Langzeitsupport ist dann eine gute Entscheidung, wenn er mit einem Datum endet. Legen Sie fest, bis wann die Anwendung auf einer unterstützten Version laufen soll, wer die Migration verantwortet und welche Zwischenziele gelten. Wie lange PHP-Zweige offiziell gepflegt werden, erklärt Der Release-Zyklus von PHP.
Ob sich ein Upgrade oder ein Backport für Ihr System eher lohnt, wägt der Beitrag PHP-Upgrade oder Backport? ab.
Wie hilft PHP SOS konkret?
- Lage bewerten: Wir prüfen Version, Paketquelle und Patch-Stand Ihrer Altsysteme und ob sie Spuren eines Angriffs zeigen.
- Angebote prüfen: Wir gleichen die schriftlichen Zusagen eines Langzeitsupport-Anbieters mit Ihrem tatsächlichen Bestand ab.
- Brücke absichern: Bis zum Upgrade setzen wir die Übergangsmaßnahmen von php.net und schränken die Erreichbarkeit ein.
- Ausstieg umsetzen: Mit der Migration von PHP 8.1 und älter planen und testen wir den Wechsel auf eine unterstützte Version.
Häufige Fragen
Was ist PHP Extended Support?
Damit sind Angebote gemeint, die PHP-Versionen nach dem offiziellen Supportende weiter mit Sicherheitskorrekturen versorgen. Das können Linux-Distributionen, Drittanbieter-Repositories oder kommerzielle Dienste wie TuxCare ELS oder Zend/HeroDevs sein.
Deckt kommerzieller Langzeitsupport PHP2Shell ab?
TuxCare gibt auf seiner Website an, PHP2Shell-Korrekturen für ausgelaufene PHP-Versionen bereitgestellt zu haben. Für Ihre konkrete Version, Ihr Paket und Ihr Betriebssystem sollten Sie das trotzdem schriftlich bestätigen lassen und im Changelog nachprüfen.
Ist Langzeitsupport eine Alternative zum Upgrade?
Nur auf Zeit. Er hält die PHP-Laufzeit gepatcht, aber nicht das CMS, die Erweiterungen und den eigenen Code, die oft ebenfalls veraltet sind. Ein Ausstiegsdatum gehört deshalb in jede Entscheidung für Langzeitsupport.
Was passiert, wenn der Langzeitsupport-Vertrag endet?
Laut cPanel-Dokumentation zu TuxCare laufen die installierten Pakete weiter, erhalten aber keine neuen Sicherheitsupdates mehr. Das System ist dann wieder in derselben Lage wie vorher, nur später.
Gilt das Thema auch für PHP 8.2?
Ja, bald. PHP 8.2 erhält mit 8.2.35 noch die PHP2Shell-Korrektur, erreicht aber am 31.12.2026 das Ende der Unterstützung. Wer 8.2 betreibt, sollte den Wechsel jetzt planen.