php2shell auf PHP 7.4, 8.0 und 8.1: was jetzt hilft

Stand: 25. Oktober 2026. Alle Uhrzeiten in UTC, sofern nicht anders angegeben.

Gegen die kritischen Lücken CVE-2026-109618 und CVE-2026-109619, bekannt als php2shell, hat das PHP-Projekt am 21. Oktober nur vier Versionen veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter bekommen vom Projekt keine Updates mehr. Was seit dem Patch passiert ist, steht in php2shell nach dem Patch.

Laut W3Techs liefen am 24. Oktober 26,8 Prozent der PHP-Websites mit bekannter Version auf PHP 7 und 7,7 Prozent auf PHP 5. Dieser Artikel sammelt, welche Wege es für diese Versionen gibt, was jeder davon belegt leistet und wie Sie prüfen, ob Ihr System tatsächlich geschützt ist.

Das Wichtigste in Kürze

• Das PHP-Team hat für 7.4, 8.0 und 8.1 Korrekturen als Quellcode veröffentlicht, ausdrücklich als „Minimal mitigation for EOL version“. Neue Versionsnummern, Tarballs oder Windows-Builds gibt es dafür nicht.
• Debian (über Freexian), Ubuntu (über Ubuntu Pro), Red Hat und cPanel haben gepatchte Pakete für ältere Versionen ausgeliefert, teils bis PHP 5.5.
• Mehrere deutsche Hoster haben auch ihre alten PHP-Versionen gepatcht, darunter Hetzner, all-inkl und hosting.de.
• Keinen Fix gibt es in den offiziellen Docker-Images und in den Laufzeitumgebungen von Google Cloud für 8.1 und älter.
• An der Ausgabe von php -v sehen Sie nicht, ob der Fix drin ist.

Ist meine Version überhaupt betroffen?

Die Quellen widersprechen sich hier, und das ist für Scanner und Audits wichtig:

Ein Scanner, der sich nur auf den CVE-Eintrag stützt, kann eine PHP-7.4-Installation also als „nicht betroffen“ melden. Das PHP-Team, NVD und die Distributionen behandeln diese Versionen dagegen als betroffen und liefern Korrekturen dafür.

Weg 1: das Paket der Distribution

Wer PHP aus den Paketquellen seiner Linux-Distribution bezieht, bekommt den Fix dort, sofern die Version noch gepflegt wird:

Zwei Einschränkungen: Die Debian-Pakete für 7.4 und älter kommen nicht aus den regulären Debian-Quellen, sondern aus dem Extended-LTS-Archiv von Freexian. Die Ubuntu-Pakete für 20.04 und älter gibt es nur mit einem Ubuntu-Pro-Abonnement. Wer beides nicht eingebunden hat, bekommt den Fix über apt upgrade nicht.

Weg 2: der Hoster

Bei Shared Hosting und Managed Servern liegt PHP beim Anbieter. Was einige Hoster öffentlich zu alten Versionen gesagt haben:

Das gilt für die Webhosting-Produkte. Auf einem eigenen V-Server oder Root-Server ist der Kunde selbst zuständig, wie bei Weg 1.

Weg 3: selbst bauen aus den Backports

Das PHP-Team hat in php-src drei eigene Branches angelegt, jeweils mit einem einzigen Commit vom 18. Oktober:

• PHP-7.4-CVE-2026-109618-109619 (Commit 712e60f9edfd)
• PHP-8.0-CVE-2026-109618-109619 (Commit 82f8f31b16a0)
• PHP-8.1-CVE-2026-109618-109619 (Commit 1d7dec178a09)

Die Commit-Nachricht lautet „Minimal mitigation for EOL version“. Laut php.net sind die Backports gedacht „to help people building from source or without access to an LTS vendor“. Was das praktisch bedeutet:

• Keine neue Version. Tags wie php-7.4.34 oder php-8.1.35 gibt es nicht. Ein Build aus dem 8.1-Branch meldet sich weiter als 8.1.34.
• Keine Pflege. Zu einem fehlschlagenden Test im 7.4-Branch (Issue #24599) schrieb PHP-Entwickler Ilija Tovilo: „7.4 is out of support. We only provided patches for these versions to help out distributions.“ Das Issue wurde als „not planned“ geschlossen.
• Bekannte Stolperstelle beim Bauen. Laut Issue #24649 erzeugt der 8.1-Patch die Zend-VM-Dateien neu. Wer dafür PHP 8.5 als Host-PHP nutzt, bekommt fehlerhaften Code. Die Antwort im Issue: einen weiteren Commit zurückportieren oder das Skript mit einer niedrigeren PHP-Version laufen lassen. Dazu der Hinweis, in 8.1 fehlten „many other patches“.

Weg 4: ein kommerzieller LTS-Anbieter

Zend (Perforce) schreibt am 22. Oktober, für seine PHP-LTS-Kunden Patches „including PHP 7.2, 7.3, 7.4, 8.0, and 8.1“ zeitgleich mit dem Community-Release bereitgestellt zu haben. Bezogen werden sie über den kostenpflichtigen LTS-Dienst. Weitere Anbieter werben ebenfalls mit Fixes für alte Versionen; für sie habe ich keine Primärquelle gefunden, die ich hier zitieren könnte.

Wo es keinen Fix gibt

• Offizielle Docker-Images: Die Images php:7.4, php:8.0 und php:8.1 werden nicht mehr gebaut. Das Projekt docker-library/php führt nur noch 8.2 bis 8.5, und der Sicherheits-Commit vom 21. Oktober aktualisiert nur diese.
• Windows: Auf windows.php.net gibt es für 7.4, 8.0 und 8.1 keine Builds nach 7.4.33, 8.0.30 und 8.1.34.
• Google Cloud: „Applications on PHP 5.5, PHP 7.2, PHP 7.3, PHP 7.4, or PHP 8.1 remain vulnerable and must be upgraded to PHP 8.2 or newer.“
• Laravel Vapor: Für PHP 8.0 und 8.1 gibt es laut Laravel keinen Patch.

Woran Sie erkennen, ob der Fix drin ist

Die Versionsnummer allein sagt es nicht. Ubuntu hat den Fix in ein Paket mit PHP 7.4.3 eingebaut, cPanel ohne Versionswechsel, und ein Build aus dem Backport-Branch meldet sich mit der alten Nummer. Maßgeblich ist das Paket:

# Debian, Ubuntu: installierte Paketversion mit der Tabelle oben vergleichen
dpkg -l 'php7.4*' | grep ^ii

# RHEL und Abkömmlinge: Changelog nach den CVE-Nummern durchsuchen
rpm -q --changelog php-common | grep -E 'CVE-2026-(109618|109619)'

Prüfen Sie die Version, die tatsächlich Webanfragen bedient, also PHP-FPM oder das Apache-Modul, nicht nur die Kommandozeile. Bei selbst gebautem PHP bleibt nur der Nachweis, aus welchem Commit gebaut wurde.

Was die offiziellen Stellen empfehlen

• PHP-Team: beim Anbieter oder der Distribution nach zurückportierten Fixes fragen „or upgrade to a supported version“.
• CISA: Wer PHP 8.1 oder älter betreibt oder nicht sofort aktualisieren kann, soll die Systeme vom Netz nehmen, bis sie gepatcht oder aktualisiert sind.
• Google Cloud: auf PHP 8.2 oder neuer aktualisieren.

Alle oben genannten Wege schließen diese beiden Lücken. Keiner davon bringt die übrigen Korrekturen, die seit dem Ende der jeweiligen Version in PHP geflossen sind. Was der Umstieg auf eine gepflegte Version auslöst, steht in PHP 7.4 auf PHP 8.4. Wer dabei auf 8.2 landet, hat nur bis zum 31. Dezember 2026 Ruhe: PHP 8.2 End of Life.

Häufige Fragen

Ist PHP 7.4 von php2shell betroffen? Laut NVD ja, für beide Lücken. Das PHP-Team hat dafür eigens einen Backport veröffentlicht. Nur der CVE-Eintrag führt 7.4 nicht als betroffen.

Gibt es PHP 7.4.34 oder 8.1.35? Nein. Das PHP-Team hat keine neuen Versionen für diese Zweige veröffentlicht, nur Quellcode-Korrekturen.

Mein Hoster zeigt PHP 7.4.33 an. Bin ich geschützt? Die Nummer sagt das nicht. Entscheidend ist, ob der Hoster den Fix eingespielt hat. Mehrere Hoster haben das öffentlich bestätigt; fragen Sie im Zweifel nach.

Reichen die Übergangsmaßnahmen aus dem Advisory? Laut PHP-Team verringern sie die Angriffsfläche, machen eine Installation aber nicht sicher. Vollständig hilft nur der Fix.

Quellen

• php.net: Security advisory vom 21.10.2026
• php-src: Backport-Branch 7.4, 8.0, 8.1
• php-src #24599, #24649
• GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
• CVE-Eintrag CVE-2026-109618
• NVD: CVE-2026-109618, CVE-2026-109619
• Freexian: ELA-1853-1 php7.4
• Ubuntu: USN-8948-1, USN-8948-2
• Red Hat: CVE-2026-109618
• cPanel: EasyApache 4 Change Log
• Hetzner Status
• all-inkl: Wichtige Informationen
• hosting.de: Sicherheitsupdate PHP
• Zend: php2shell patches now available
• docker-library/php: versions.json
• windows.php.net: Archiv
• Google Cloud: Responding to core PHP vulnerabilities
• Laravel: PHP critical vulnerability response updates
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• W3Techs: Usage statistics of PHP (Stand 24.10.2026)

Was ein End of Life grundsätzlich bedeutet und warum es nicht beim Stichtag weh tut, sondern bei der nächsten Lücke, steht im Glossar.