Kurz gesagt: Für die PHP-8.1-Sicherheitslücke PHP2Shell gibt es kein offizielles Update. Das PHP-Projekt liefert für 7.4, 8.0 und 8.1 nur minimale Quell-Backports, keine fertigen Releases. Wer diese Versionen betreibt, braucht einen bestätigten Backport seines Anbieters oder Übergangsmaßnahmen und sollte den Umstieg auf eine unterstützte Version jetzt planen.
Gibt es gegen die PHP-8.1-Sicherheitslücke ein Update?
Nicht vom PHP-Projekt. Am 21. Oktober 2026 erschienen offizielle Korrekturen nur für die unterstützten Zweige: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten keine offiziellen Updates mehr.
Betroffen sind sie trotzdem. Laut Fachpresse reichen die verwundbaren Versionen nahezu durchgehend bis PHP 5.4 zurück. Wer eine dieser Versionen öffentlich erreichbar betreibt, hat also eine kritische Lücke mit CVSS v4.0 9.2 ohne fertigen Patch.
Für viele Unternehmen ist das eine Überraschung, denn solche Systeme laufen oft seit Jahren stabil und unauffällig. Dass eine Version keine Updates mehr bekommt, merkt man im Alltag nicht, bis eine Lücke wie PHP2Shell auftaucht. Die Quell-Backports für 7.4, 8.0 und 8.1 sind eine Ausnahme und keine Wiederaufnahme der regulären Pflege.
Was die Quell-Backports bedeuten
Für 7.4, 8.0 und 8.1 gibt es minimale Quell-Backports. Das sind Korrekturen im Quellcode, die auf diese älteren Zweige übertragen wurden. Sie sind kein offizielles Release mit Versionsnummer, getestetem Paket und Changelog.
Praktisch heißt das: Jemand muss den Backport übernehmen, PHP daraus neu bauen, testen und ausrollen. Das kann auf drei Wegen passieren:
- Ihre Distribution übernimmt die Korrektur in ihre Pakete, etwa im Rahmen einer Langzeitpflege.
- Ihr Hoster baut eigene PHP-Pakete und spielt den Backport ein.
- Sie selbst oder ein Dienstleister bauen PHP aus den Quellen. Das ist anspruchsvoll und muss bei jeder weiteren Lücke wiederholt werden.
Ob Ihr System einen Backport erhalten hat, prüfen Sie am Paket-Changelog:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-Familie
Paketnamen weichen je Distribution und Paketquelle ab. Fehlt ein Eintrag, fragen Sie den Anbieter. Wie die Prüfung im Detail funktioniert, steht unter PHP-Version und Patchstand richtig prüfen.
Den alten Server bis zur Migration absichern
Solange kein bestätigter Backport läuft, gelten die Übergangsmaßnahmen von php.net: nicht überschreibbares memory_limit=-1 mit Speichergrenze über cgroup, post_max_size von 8M oder 32M mit upload_max_filesize darunter und session.upload_progress.enabled=0 in der Serverkonfiguration, danach alle Worker neu starten. Sie sind kein vollständiger Schutz. Details unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
Dazu kommen Maßnahmen, die die Erreichbarkeit verringern: Admin-Bereiche nur über VPN oder freigegebene IP-Adressen, nicht benötigte Websites abschalten, Zugriffe auf den Server eng begrenzen. Das BSI empfiehlt, Server ohne Update vorübergehend vom Netz zu nehmen. Für eine alte, schwer migrierbare Anwendung kann eine abgeschottete Lösung die ehrlichere Antwort sein als ein Betrieb im offenen Internet.
Lief ein Server mit PHP 8.1 oder älter seit dem 17. Oktober ungeschützt im Netz, nehmen Sie das ernst: Das BSI rechnete mit schneller großflächiger Ausnutzung. Sichern Sie die Logs ab dem 20. Oktober und lassen Sie ihn auf Spuren prüfen, bevor Sie migrieren.
Migration planen: auf welche Version?
Das Ziel ist eine Version, die das PHP-Projekt unterstützt und die Ihre Anwendung verträgt. PHP 8.2 schließt die Lücke ab 8.2.35, erreicht aber am 31.12.2026 das Ende der Unterstützung. Wer jetzt migriert, sollte deshalb möglichst auf 8.3 oder neuer gehen, sofern die Anwendung es erlaubt. Den aktuellen Stand nennt php.net auf der Seite der unterstützten Versionen.
Welche PHP-Version Ihr CMS oder Shop unterstützt, prüfen Sie laut Systemanforderungen des Herstellers, zum Beispiel auf wordpress.org, shopware.com oder typo3.org. Häufig muss zuerst die Anwendung selbst aktualisiert werden, bevor PHP wechseln kann. Ein typischer Fall sind ältere Shops, die wir auf der Seite Shopware 5 beschreiben. Hintergründe zu den Folgen veralteter Versionen finden Sie unter PHP-End-of-Life: Risiken veralteter Versionen.
| Schritt | Inhalt |
|---|---|
| Bestand | PHP-Version, Anwendung, Erweiterungen, eigene Anpassungen |
| Anforderungen | unterstützte PHP-Versionen laut Hersteller |
| Testumgebung | Kopie mit neuer PHP-Version, Fehlerprotokoll auswerten |
| Umstellung | geplantes Wartungsfenster, Rückweg vorbereitet |
| Nacharbeit | Übergangswerte prüfen, Überwachung einrichten |
Wie hilft PHP SOS konkret?
Mit der Migration von PHP 8.1 und älter führen wir Sie von der Altversion zu einer unterstützten:
- Sofort absichern: Backport-Stand prüfen, Übergangsmaßnahmen setzen, Erreichbarkeit verringern.
- Spuren prüfen: Logs ab dem 20. Oktober sichern und auf Auffälligkeiten auswerten.
- Migration vorbereiten: Kompatibilität laut Hersteller klären, Testumgebung aufbauen, Fehler beheben.
- Umstellen und nachweisen: neue PHP-Version einspielen, alle Prozesse neu starten, Stand dokumentieren.
Häufige Fragen
Ist PHP 8.1 von PHP2Shell betroffen?
Laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen, PHP 8.1 eingeschlossen. Das PHP-Projekt veröffentlicht für 8.1 keine offiziellen Updates mehr, sondern nur minimale Quell-Backports.
Was ist ein Quell-Backport?
Eine Korrektur im Quellcode, die auf einen älteren Versionszweig übertragen wurde. Sie ist kein fertiges Release: Jemand muss sie übernehmen, PHP neu bauen, testen und ausrollen. Das kann Ihr Distributionsanbieter, Ihr Hoster oder ein Dienstleister übernehmen.
Reicht es, auf PHP 8.2 zu wechseln?
Kurzfristig schließt PHP 8.2.35 die Lücke. PHP 8.2 erreicht aber am 31.12.2026 das Ende der Unterstützung. Wer ohnehin migriert, sollte deshalb prüfen, ob die Anwendung laut Hersteller auch 8.3 oder neuer unterstützt.
Mein Shop läuft nur mit PHP 7.4. Was nun?
Dann sind zwei Dinge parallel nötig: den Server mit Übergangsmaßnahmen und Abschottung absichern und die Anwendung auf eine Version bringen, die eine unterstützte PHP-Version verträgt. Welche das ist, steht in den Systemanforderungen des Herstellers.