Kurz gesagt: Ob PHP-Upgrade oder Backport die richtige Wahl ist, hängt davon ab, wie lange Ihr System noch laufen soll und wie gut der Backport belegt ist. Ein Backport der eigenen Distribution auf einem unterstützten Betriebssystem ist ein vollwertiger Weg. Quell-Backports, Drittquellen und kommerzieller Langzeitsupport für PHP 8.1 und älter sind Brücken mit Ablaufdatum. Auf Dauer hilft nur der Umstieg auf eine PHP-Version, die das PHP-Projekt noch offiziell unterstützt.
Warum die Frage nach PHP2Shell drängt
Am 21.10.2026 hat das PHP-Projekt PHP2Shell in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Für PHP 8.1 und älter gibt es keine offiziellen Releases mehr, nur minimale Quell-Backports für 7.4, 8.0 und 8.1. Laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen.
Damit stehen viele Betreiber von Altsystemen vor derselben Frage: Reicht es, die Lücke irgendwie zu flicken, oder muss jetzt das Upgrade her, das seit Jahren aufgeschoben wurde? Was ein Upgrade praktisch bedeutet, beschreibt unser Angebot zur Migration von PHP 8.1 und älter. Was ohne offizielles Update gilt, steht unter PHP 8.1 und älter: Was jetzt gilt. Dieser Beitrag hilft bei der Abwägung dazwischen.
Welche Arten von Backports es gibt
„Backport“ ist ein Sammelbegriff. Gemeint ist immer, dass eine Korrektur aus einer neueren Version in eine ältere übernommen wird. Wer das tut und wie gut es geprüft ist, unterscheidet sich aber stark.
- Backport der Distribution: Debian, Ubuntu, Red Hat und andere übernehmen Sicherheitskorrekturen in die PHP-Pakete ihrer unterstützten Releases. Die Versionsnummer bleibt dabei oft gleich; laut Berichten zeigt etwa Ubuntu 24.04 nach dem Update weiter 8.3.6. Belegt wird der Fix über den Paket-Changelog und die Sicherheitsmeldungen der Distribution.
- Drittquelle: Das Repository sury.org von Ondřej Surý hat laut Berichten Builds für alle Zweige von 5.6 bis 8.5 bereitgestellt. Es ist nicht das Sicherheitsarchiv von Debian. Details stehen unter Das sury.org-Repository.
- Quell-Backport des PHP-Projekts: Für 7.4, 8.0 und 8.1 gibt es minimale Patches im Quellcode, aber keine fertigen Releases. Wer sie nutzt, muss PHP selbst bauen, testen und künftig selbst pflegen.
- Kommerzieller Langzeitsupport: Anbieter wie TuxCare ELS oder Zend/HeroDevs bieten Pflege für alte Versionen. Ob und wann sie PHP2Shell abdecken, muss schriftlich bestätigt werden; das war in den bekannten Quellen nicht belegt. Mehr dazu unter Langzeitsupport für alte PHP-Versionen.
PHP-Upgrade oder Backport: der Vergleich
| Kriterium | Upgrade auf unterstützte Version | Backport (je nach Art) |
|---|---|---|
| Schutz gegen PHP2Shell | Ja, mit 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 | Ja, wenn vollständig und belegt |
| Künftige Sicherheitsupdates | Offiziell bis zum Supportende der Version | Nur, solange der jeweilige Anbieter pflegt |
| Nachweis | Versionsnummer plus Neustart | Paket-Changelog mit CVE-Nummern, Bestätigung des Anbieters |
| Aufwand jetzt | Mittel bis hoch, Kompatibilitätstests nötig | Gering bei Distribution, hoch bei Eigenbau |
| Aufwand später | Gering bis zum nächsten Versionssprung | Wächst mit jeder neuen Lücke |
| Risiko für die Anwendung | Inkompatibilitäten mit altem Code und Erweiterungen | Gering, Verhalten bleibt weitgehend gleich |
| Eignung als Dauerlösung | Ja | Nur der Distributions-Backport im Rahmen eines unterstützten Betriebssystems |
Die Zeile „Aufwand später“ ist die wichtigste. PHP2Shell wird nicht die letzte Lücke gewesen sein. Jeder Monat auf einer Version ohne offiziellen Support bedeutet, dass die nächste Meldung wieder dieselbe Frage aufwirft.
Welche Zielversion beim Upgrade?
Laut php.net gilt für jeden PHP-Zweig: zwei Jahre aktive Unterstützung, danach zwei Jahre nur Sicherheitskorrekturen. Daraus ergeben sich diese Enddaten für den Sicherheitssupport:
| Version | Sicherheitssupport bis |
|---|---|
| PHP 8.2 | 31.12.2026 |
| PHP 8.3 | 31.12.2027 |
| PHP 8.4 | 31.12.2028 |
| PHP 8.5 | 31.12.2029 |
Ein Upgrade auf 8.2 ist deshalb nur noch eine kurze Zwischenstation. Wer ohnehin migriert, sollte eine Version mit längerem Horizont anpeilen, sofern CMS, Shop und Erweiterungen sie unterstützen. Das prüfen Sie in den Systemanforderungen des Herstellers, nicht aus dem Gedächtnis. Wie der Release-Zyklus funktioniert, erklärt PHP-Versionen und Release-Zyklus.
Egal welcher Weg: Nach dem Einspielen müssen alle PHP-Prozesse neu gestartet werden. Ein Backport, der nur auf der Festplatte liegt, schützt nicht, solange alte Worker im Speicher laufen.
Eine pragmatische Reihenfolge für Altsysteme
- Sofort: Übergangsmaßnahmen laut php.net setzen oder das System vorübergehend vom Netz nehmen, wenn kein belegter Fix verfügbar ist.
- In den nächsten Tagen: Einen belegten Backport einspielen, möglichst aus der eigenen Distribution oder mit schriftlicher Bestätigung des Anbieters.
- Parallel: Kompatibilität der Anwendung mit einer unterstützten Version prüfen und einen Zeitplan festlegen.
- In den nächsten Monaten: Upgrade auf die Zielversion, in einer Testkopie vorbereitet, mit Rückfallplan.
Den Backport als Brücke zu sehen, nicht als Ziel, ist der entscheidende Gedanke.
Wann Sie dafür keinen Dienstleister brauchen
Läuft Ihr Server auf einem unterstützten Debian, Ubuntu oder RHEL und liefert die Distribution den Backport, genügt ein reguläres Update mit Neustart und ein Blick in den Changelog. Das schafft ein erfahrener Admin allein. Hilfe lohnt sich bei Eigenbauten, Drittquellen, sehr alten Versionen oder einer Anwendung, deren Kompatibilität niemand mehr überblickt.
Wie hilft PHP SOS konkret?
- Wir prüfen, welche PHP-Versionen und Paketquellen auf Ihren Servern laufen und ob ein belegter Fix vorliegt.
- Wir spielen Backports ein, starten neu und dokumentieren den Nachweis über den Changelog.
- Wir testen Ihre Anwendung in einer Kopie gegen die Zielversion und benennen Inkompatibilitäten.
- Wir planen und begleiten das Upgrade im Rahmen der Migration von PHP 8.1 und älter.
Fazit
Der Backport der Distribution ist ein vollwertiger Weg, alle anderen Backports sind Brücken. Wer auf PHP 8.1 oder älter festsitzt, sollte den Backport nutzen, um Zeit für das Upgrade zu gewinnen, nicht um es weiter aufzuschieben.
Häufige Fragen
Ist ein Backport genauso sicher wie ein Upgrade?
Für die konkret behobene Lücke kann ein Backport gleichwertig sein, wenn er vollständig und belegt ist. Er behebt aber nur, was zurückportiert wurde. Ein Upgrade auf eine unterstützte Version bringt zusätzlich alle künftigen offiziellen Sicherheitsupdates.
Woran erkenne ich, dass mein Backport PHP2Shell abdeckt?
Am Paket-Changelog: Dort sollten die CVE-Nummern CVE-2026-109618 und CVE-2026-109619 genannt sein. Unter Debian und Ubuntu zeigt das apt-get changelog, in der RHEL-Familie rpm -q --changelog. Die Versionsnummer allein ist kein Beleg.
Wie lange bekommt PHP 8.2 noch Sicherheitsupdates?
Laut php.net endet der Sicherheitssupport für PHP 8.2 am 31.12.2026. Wer heute auf 8.2 aktualisiert, sollte den nächsten Schritt also gleich mitplanen.
Lohnt sich kommerzieller Langzeitsupport für alte PHP-Versionen?
Er kann eine Brücke sein, wenn ein Upgrade kurzfristig unmöglich ist. Lassen Sie sich schriftlich bestätigen, ob und ab wann PHP2Shell abgedeckt ist. In den bisher bekannten Quellen war das nicht belegt.