Kurz gesagt: Von der PHP-Sicherheitslücke PHP2Shell sind die Zweige 8.2 bis 8.5 bis zu den Releases vom 21. Oktober 2026 betroffen, laut Fachpresse nahezu alle Versionen bis zurück zu PHP 5.4. Behoben ist sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr, sondern nur minimale Quell-Backports für 7.4, 8.0 und 8.1.
Welche Versionen hat die PHP-Sicherheitslücke betroffen?
PHP2Shell umfasst die beiden Lücken CVE-2026-109618 und CVE-2026-109619, jeweils mit CVSS v4.0 9.2 bewertet. Beide erlauben Ausführung von Schadcode aus der Ferne ohne Anmeldung. Am 21. Oktober 2026 um 14:00 UTC (16 Uhr deutscher Zeit) hat das PHP-Projekt Korrekturen für alle unterstützten Zweige veröffentlicht.
| PHP-Zweig | Letzter Stand vor dem Fix | Behoben ab | Unterstützung |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | offiziell unterstützt |
| 8.4 | 8.4.26 | 8.4.27 | offiziell unterstützt |
| 8.3 | 8.3.35 | 8.3.36 | offiziell unterstützt |
| 8.2 | 8.2.34 | 8.2.35 | endet am 31.12.2026 |
| 8.1, 8.0, 7.4 | alle Stände | kein offizielles Release | nur minimale Quell-Backports |
| 7.3 bis 5.4 | laut Fachpresse nahezu alle betroffen | kein Update | seit Jahren ohne Unterstützung |
Die Angaben zu 8.2 bis 8.5 stammen aus den Meldungen von php.net. Die Aussage zu den Versionen bis PHP 5.4 stammt aus der Fachpresse; eine vollständige offizielle Liste für Altversionen gibt es nicht.
Für Nicht-Techniker in wenigen Sätzen: Steht auf Ihrem Server eine Version aus der Spalte „Behoben ab“ oder höher und wurden danach alle PHP-Prozesse neu gestartet, ist PHP2Shell geschlossen. Steht dort eine ältere Nummer, ist entweder ein Backport im Spiel, den Ihr Anbieter bestätigen muss, oder die Lücke ist offen. Fragen Sie Ihre IT oder Ihren Hoster im Zweifel genau nach diesen drei Punkten: Version, Backport, Neustart.
Betroffene Betriebsarten
Die Versionsnummer ist nur die halbe Antwort. Betroffen sind alle gängigen Arten, PHP auf einem Webserver zu betreiben: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team stuft das Risiko bei mod_php am höchsten ein, weil dort ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft. Einzelheiten dazu unter Warum mod_php das höchste Risiko trägt.
Kein Schutz ergibt sich aus der Anwendung: Ob WordPress, Shopware, TYPO3, Laravel oder eine Eigenentwicklung, ein Update der Anwendung schliesst die Lücke in PHP nicht.
Backports: wenn die Versionsnummer täuscht
Viele Linux-Distributionen und Hoster liefern PHP in eigenen Paketen aus. Statt auf eine neue Upstream-Version zu springen, übernehmen sie die Korrektur als Backport in ihre bestehende Version. Das hat eine praktische Folge: Die angezeigte Nummer bleibt alt. Ein Beispiel aus der aktuellen Lage ist Plesk, das weiter 8.2.34 anzeigen kann, obwohl der Fehler behoben ist.
Für Sie heisst das: Die Tabelle oben gilt für die offiziellen Releases von php.net. Bei Paketen aus Ihrer Distribution oder vom Hoster entscheiden der Paketstand und die Bestätigung des Anbieters. Wie Sie beides prüfen, zeigt PHP-Version und Patchstand richtig prüfen. Für den Schnelltest auf der Kommandozeile:
php -v
apt policy php8.3-fpm # Debian/Ubuntu, Paketname je Version und Quelle verschieden
dnf info php-fpm # RHEL-Familie
Eine behobene Versionsnummer auf der Festplatte heisst noch nicht, dass sie läuft. Erst nach dem Neustart aller PHP-Prozesse arbeitet der Server mit dem korrigierten Code.
Was gilt für PHP 8.1 und älter?
Für PHP 8.1, 8.0 und 7.4 gibt es nur minimale Quell-Backports, also Korrekturen im Quellcode, die jemand selbst übernehmen und kompilieren muss. Offizielle Releases erscheinen nicht. Manche Distributionen mit Langzeitpflege bauen solche Korrekturen in ihre Pakete ein; ob das für Ihr System gilt, lässt sich nur am Paket-Changelog oder beim Anbieter klären.
Langfristig führt kein Weg an einer unterstützten Version vorbei. Welche PHP-Version Ihr CMS oder Shop verträgt, prüfen Sie laut Systemanforderungen des Herstellers, etwa auf wordpress.org, shopware.com oder typo3.org. Mehr dazu unter PHP 8.1 und älter: Was jetzt gilt.
Und CVE-2026-115560?
Am 23. Oktober hat php.net einen Hinweis zu einer dritten Lücke veröffentlicht. Sie greift nur bei einer ungewöhnlichen Session-Konfiguration. Eine behobene Version gibt es nach dem Stand vom 25. Oktober noch nicht; bis zum nächsten regulären Bugfix-Release lautet die Abhilfe session.upload_progress.enabled=0. Eine Versionsliste wird erst mit dem vollständigen Advisory erwartet.
Wie hilft PHP SOS konkret?
- Inventar: Wir erfassen alle PHP-Versionen auf Ihren Servern, auch Zweitinstallationen für einzelne Websites, die gern übersehen werden.
- Abgleich: Für jede Installation klären wir, ob ein offizielles Release, ein Distributions-Backport oder keine Korrektur vorliegt.
- Update mit Nachweis: Über den PHP-Patch-Service spielen wir die Korrektur ein und starten alle Prozesse neu.
- Migrationsplan: Für Versionen ohne offizielle Updates planen wir mit der Migration von PHP 8.1 und älter den Umstieg und sichern den Server bis dahin ab.
Häufige Fragen
Ist PHP 8.3.35 noch sicher?
Nein, sofern Ihr Anbieter keinen Backport eingespielt hat. 8.3.35 ist der letzte Stand vor dem Fix; behoben ist PHP2Shell im Zweig 8.3 ab 8.3.36. Bei Distributionspaketen kann die Nummer gleich bleiben, obwohl der Fehler behoben ist. Dann zählt der Paket-Changelog oder die Bestätigung des Anbieters.
Ist PHP 7.4 von PHP2Shell betroffen?
Laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen. Für 7.4, 8.0 und 8.1 gibt es nur minimale Quell-Backports und keine offiziellen Releases. Ein Umstieg auf eine unterstützte Version ist der belastbare Weg.
Warum zeigt Plesk 8.2.34 an, obwohl gepatcht wurde?
Distributionen und Hoster übernehmen Korrekturen teils als Backport in ihre bestehenden Pakete. Die Versionsnummer bleibt dann gleich, der Fehler ist trotzdem behoben. Prüfen Sie den Paketstand oder lassen Sie sich den Patch vom Anbieter bestätigen.
Welche PHP-Version sollte ich jetzt wählen?
Eine unterstützte Version, die Ihre Anwendung laut Systemanforderungen des Herstellers freigibt. PHP 8.2 erreicht am 31.12.2026 das Ende der Unterstützung; wer jetzt ohnehin wechselt, sollte das einplanen.