Security 21.10.2026, 00:34 Aktualisiert: 21.10.2026, 00:45

Kritische PHP-Lücken: PHP2Shell-Demo und Patch am 21. Oktober

PHP kündigt zwei kritische Lücken an, eine PHP2Shell-Demo zeigt Codeausführung. Was du jetzt prüfen solltest und worauf es bei Plesk und Updates ankommt.

Von Moritz Mantel · Veröffentlicht: 21.10.2026, 00:34 · Aktualisiert: 21.10.2026, 00:45

Stand: 21.10.2026, 00:45 Uhr MESZ. Vorab-Einschätzung vor dem angekündigten PHP-Sicherheitsrelease, ergänzt um die öffentliche PHP2Shell-Demo. Eine vollständige Liste betroffener Versionen, technische Details und Fixstände stehen noch aus.

Kurzfassung

Angekündigt: Zwei kritische PHP-Sicherheitslücken mit jeweils CVSS 4.0 von 9,2. Geplanter Release: 21. Oktober 2026, 14:00 UTC, also 16:00 Uhr MESZ.
Öffentliche Demo: Das PHP2Shell-Video zeigt Codeausführung über HTTP gegen mehrere bekannte Anwendungen. Neben Apache mit mod_php kommen auch ausdrücklich als PHP-FPM bezeichnete Exploits vor. Das ist ein konkreter Anlass zur Vorbereitung.
Bin ich betroffen? Das lässt sich derzeit nicht verlässlich beantworten. Erfasse jetzt deine PHP-Installationen und die Anwendungen, die sie tatsächlich verwenden.
Bei Plesk: System-PHP und die von Plesk bereitgestellten PHP-Versionen getrennt prüfen. Ein einzelnes php -v erfasst keinen ganzen Hosting-Server.
Bis zum Patch: Updateweg, Zuständigkeiten und Wartungsfenster vorbereiten. disable_functions, ein gesperrter SSH-Zugang oder eine aktive WAF sind kein belegter Schutz gegen diese Lücken.
Nach dem Release: Passenden Fix für die eigene Paketquelle bestätigen, einspielen und dafür sorgen, dass die laufenden Prozesse den neuen Code verwenden.

Quelle der Ankündigung: PHP Security Team, 20. Oktober 2026.

Was PHP bestätigt hat und was noch fehlt

Das PHP Security Team will die technischen Details sowie betroffene und korrigierte Versionen mit dem Release veröffentlichen. Sollten vorher Details öffentlich werden oder Hinweise auf aktive Ausnutzung auftauchen, kann sich die Veröffentlichung vorziehen. Die genannte Uhrzeit ist deshalb kein Grund, bis dahin alle Meldungen zu ignorieren.

Die Vorankündigung nennt keine CVE-Kennungen, betroffenen Komponenten oder konkreten Angriffsvoraussetzungen. Eine belastbare Liste betroffener und nicht betroffener PHP-Versionen lässt sich daraus ebenso wenig ableiten wie eine Entwarnung für bestimmte Betriebssysteme oder Handler. Die inzwischen veröffentlichte Demo liefert zusätzliche Hinweise, ersetzt aber diese Angaben nicht.

Ein CVSS-Wert allein beantwortet diese Fragen nicht. Für deinen Server macht es einen erheblichen Unterschied, ob eine Lücke einen üblichen Request-Pfad betrifft oder erst durch eine bestimmte Erweiterung, Konfiguration oder Anwendungsfunktion erreichbar wird.

Was die PHP2Shell-Demo zeigt

Kirill Firsov hat am Abend des 20. Oktober ein gut dreiminütiges Video unter dem Namen „php2shell“ veröffentlicht. In einer Antwort nennt er @lcfr_hax und @calif_io als Urheber von Video und Exploit.

Zu sehen sind Angriffe auf lokale Testinstanzen, unter anderem mit WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal und WHMCS. Das Werkzeug erhält eine HTTP-Zieladresse und einen auszuführenden Befehl. Bei mehreren Durchläufen erscheinen anschließend Betriebssystemausgaben und uid=33(www-data) im Terminal; teilweise wird eine angelegte Datei mit dem Inhalt pwned im Browser aufgerufen. Ein Login oder die Übergabe von Zugangsdaten ist in diesen Aufrufen nicht zu sehen.

PHP2Shell-Demo von @lcfr_hax und @calif_io, geteilt von Kirill Firsov am 20.10.2026. Das Video wird über unsere Website ausgeliefert; der Player lädt keine Inhalte von X. Die wichtigsten Beobachtungen stehen im Text.

Für die Einordnung sind zwei Details besonders relevant. Erstens zeigen die Ausgaben Codeausführung mit den Rechten des Webserver-Benutzers. Das ist bereits erheblich: Was dieser Benutzer lesen oder verändern darf, steht auch dem ausgeführten Code offen. Einen Root-Zugriff belegt die Demo nicht. Zweitens zeigt sie sowohl ein Profil für Apache mit mod_php als auch eigene PHP-FPM-Exploits. Im WHMCS-Durchlauf ist auch beim PHP-FPM-Exploit eine erfolgreiche Befehlsausgabe zu sehen. „Wir nutzen FPM“ reicht deshalb nicht als Entwarnung.

Im Banner steht PHP >= 5.4.0 RCE. Das ist die Reichweitenangabe der Demo-Autoren, noch keine vom PHP-Projekt bestätigte Versionsliste. Die sichtbaren Profile nennen konkrete Zielumgebungen, darunter Ubuntu 26.04 mit PHP 8.5.4. Weder die vollständige Serverkonfiguration noch alle Voraussetzungen lassen sich aus dem Video ablesen. Wir haben die gezeigten Ergebnisse ausgewertet, den Exploit aber nicht selbst reproduziert. Auch die Zuordnung zu den beiden angekündigten Lücken ist in der PHP-Vorankündigung noch nicht beschrieben.

Kann das schlimmer werden als Log4Shell?

Unsere Sorge ist die mögliche Breite des Problems. Die Demo zeigt mehrere verbreitete Anwendungen und mehr als eine Art, PHP im Webserver zu betreiben. PHP steckt in öffentlich erreichbaren Websites, Shops, Kundenportalen und Verwaltungsoberflächen. Dahinter stehen sehr unterschiedliche Betreiber: vom betreuten Hosting-Cluster bis zur seit Jahren unveränderten Installation, für die sich niemand mehr zuständig fühlt.

Falls sich eine der Lücken ohne Anmeldung über gewöhnliche HTTP-Anfragen zur Codeausführung ausnutzen lässt und verbreitete Standardkonfigurationen betroffen sind, halten wir einen größeren Schaden als bei Log4Shell für ein plausibles Szenario. Die Kombination aus vielen erreichbaren Anwendungen, einfacher Automatisierung und langsamer Patchverteilung wäre ausgesprochen unangenehm.

Die Demo macht dieses Szenario konkreter. Sie belegt aber noch nicht, wie viele produktive Installationen sich auf diesem Weg angreifen lassen. Die Zahl der PHP-Seiten allein reicht für den Vergleich nicht aus. Entscheidend sind die tatsächlich angreifbaren Installationen, die Voraussetzungen des Exploits und die Zeit bis zum wirksamen Update. Eine Beschränkung auf seltene Konfigurationen würde die Lage deutlich verändern.

Für den Betrieb würden wir nicht darauf wetten, nach der Veröffentlichung mehrere ruhige Tage zu haben. Eine öffentliche Demonstration ist bereits da. Wann ausführbarer Exploit-Code frei verfügbar wird oder Angriffe in der Breite beginnen, folgt daraus nicht. Den Updateablauf jetzt vorzubereiten, kostet wesentlich weniger als ihn unter Angriffsdruck zusammenzusuchen.

Zuerst erfassen: Welches PHP läuft wo?

Die folgenden Befehle sind Beispiele für Linux-Systeme. Sie erfassen Installationen, sind aber kein Test auf die angekündigten Lücken. Die Plesk-Kommandos benötigen administrative Rechte; auf deinem Produktivserver musst du die Ausgabe gegen die tatsächliche Konfiguration prüfen.

Für das PHP aus dem aktuellen Suchpfad:

command -v php
php -v
php --ini

Das zeigt die CLI-Version und deren Konfigurationsdateien. Der Webserver kann eine andere Version und eine andere php.ini verwenden. Auch Cronjobs und dauerhaft laufende Queue-Worker gehören zur Bestandsaufnahme. Die Optionen dokumentiert das PHP-Handbuch.

Plesk: Handler und Websites zuordnen

Auf einem Plesk-Linux-Server:

plesk bin php_handler --list

for php_bin in /opt/plesk/php/*/bin/php; do
  [ -x "$php_bin" ] || continue
  printf '%s: ' "$php_bin"
  "$php_bin" -r 'echo PHP_VERSION, PHP_EOL;'
done

Die Schleife zeigt die installierten CLI-Binaries im üblichen Plesk-Pfad. Benutzerdefinierte Installationen außerhalb dieses Verzeichnisses musst du ergänzen. Welche Websites einen Handler verwenden, lässt sich separat abfragen:

# Beispiel: Die ID durch einen Eintrag aus --list ersetzen.
plesk bin php_handler --get-usage -id plesk-php85-fpm

Die Befehle sind in der Plesk-Dokumentation zu PHP-Handlern beschrieben. Notiere pro Website den verwendeten Handler und die Paketquelle. Diese Zuordnung spart nach dem Release Zeit und verhindert, dass ein aktualisiertes System-PHP mit einem aktualisierten Webspace verwechselt wird.

Paketstände erfassen

Auf Debian und Ubuntu kannst du die vollständigen installierten Paketversionen auslesen:

dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 'plesk-php*'

Auf RPM-basierten Systemen:

rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^(php|plesk-php|ea-php|alt-php)'

Die Namensfilter sind Suchhilfen. Selbst gebaute Installationen oder anders benannte Pakete können fehlen. Bei Debian/Ubuntu können nicht vorhandene Paketmuster eine Fehlermeldung erzeugen. Bewahre die vollständige Paketversion einschließlich Distributionssuffix auf; ein späterer Backport muss sich nicht durch eine neue PHP-Upstream-Version zeigen.

Patchstände: Die Paketquelle entscheidet

Vor dem Advisory wären konkrete Mindestversionen geraten. Auch ein Paket, das heute als „aktuell“ angezeigt wird, ist dadurch noch kein bestätigter Fix. Für die Vorbereitung ist zunächst entscheidend, wer dein PHP liefert:

Installation	Wo der passende Fix nachgewiesen werden muss
PHP aus der Distribution	Sicherheitsmeldung und Paket-Changelog für genau das verwendete OS-Release und gegebenenfalls den Paketstream.
PHP von Plesk	Plesk-PHP-Updates und die auf dem eigenen Server verfügbaren Pakete. System-PHP separat berücksichtigen.
PHP aus einem zusätzlichen Repository	Advisory und Pakete dieses Anbieters; ein Fix der Distribution gilt nicht automatisch für fremde Pakete.
PHP im Container	Aktualisiertes Basis- beziehungsweise Anwendungsimage und der tatsächlich ausgerollte Stand aller Instanzen.
Selbst gebautes PHP	Bestätigter Upstream-Fix, erneuter Build mit den benötigten Erweiterungen und Austausch der laufenden Prozesse.
Managed Hosting	Bestätigung des Hosters für die tatsächlich genutzte PHP-Version, einschließlich Abschluss des Rollouts.

Die Tabelle beschreibt Updatewege, keinen aktuellen Verwundbarkeitsstatus. Bei einem Vendor-Backport zählt die ausdrückliche Zuordnung zum Sicherheitsfix. Sobald CVE-Kennungen vorliegen, gehören sie in diese Prüfung.

Plesk: PHP-Release und verfügbare Pakete sind zwei Termine

Im Plesk-Changelog ist zum Stand dieses Artikels noch kein Fix für diese Ankündigung dokumentiert. Der jüngste dort aufgeführte PHP-Updateblock stammt vom 28. September und nennt 8.5.11, 8.4.26, 8.3.35 und 8.2.34. Diese Versionsangaben belegen keinen Fix für die neuen Lücken.

Daraus lässt sich weder ablesen, ob Plesk intern bereits Pakete vorbereitet, noch wann sie verfügbar sein werden. Eine frühere Lieferzeit ist keine Zusage für diesen Release. Prüfe nach der Veröffentlichung sowohl die Herstellermeldung als auch den Paketkanal deines Servers.

Plesk dokumentiert für Updates einschließlich mitgelieferter Komponenten diesen Befehl:

# Erst nach Prüfung der verfügbaren Updates und im geplanten Wartungsfenster.
plesk installer --select-release-latest --upgrade-installed-components

Dieser Aufruf kann neben PHP auch andere installierte Komponenten aktualisieren. Prüfe vorher den Umfang und den Wiederherstellungsweg. Für eine gezielte Auswahl beschreibt Plesk den Weg über Tools & Settings → Updates → Update Components. Quelle: Plesk Updates.

Ein erfolgreich durchgelaufener Installer ist noch kein Nachweis, dass die angekündigten Lücken geschlossen wurden. Dafür brauchst du das bestätigte Fixpaket und den Nachweis, dass es für die betroffenen Websites tatsächlich läuft.

Hilft es, Shell-Funktionen zu sperren?

disable_functions kann die üblichen PHP-Aufrufe zum Starten externer Programme unterbinden. Eine mögliche Härtung ist beispielsweise:

disable_functions = exec,shell_exec,system,passthru,proc_open,popen,pcntl_exec

Das ist kein bestätigter Workaround für die angekündigten Lücken. Die Sperre wirkt auf PHP-Funktionen. Falls ein Fehler native Codeausführung im Interpreter ermöglicht, bildet diese Liste keine verlässliche Sicherheitsgrenze. Das PHP-Handbuch warnt ausdrücklich vor dieser Grenze von disable_functions.

Auch ohne gestartete Shell kann ausgeführter PHP-Code erheblichen Schaden anrichten: lesbare Anwendungskonfigurationen auslesen, mit den darin hinterlegten Zugangsdaten auf die Datenbank zugreifen oder beschreibbare Webdateien verändern. Der Schaden hängt von den Rechten des Prozesses ab. Root-Zugriff folgt daraus nicht automatisch.

Wenn du die Funktionen einschränkst, ergänze bestehende Sperren, statt sie versehentlich zu ersetzen. Prüfe die wirksame Einstellung im jeweiligen Web-Handler und teste die Anwendung. PDF-Erzeugung, Bildverarbeitung oder andere Funktionen, die externe Programme aufrufen, können dadurch ausfallen.

Ein verbotener SSH-Login nimmt einem bereits laufenden PHP-Prozess ebenfalls nicht seine Betriebssystemrechte. Und open_basedir ist laut PHP-Dokumentation nur eine zusätzliche, unvollständige Einschränkung. Für Shared Hosting bleiben getrennte Benutzer, passende Dateirechte und wirksame Isolation auf Betriebssystemebene wichtig. Keine dieser Maßnahmen sollte ohne Kenntnis des Angriffswegs als Lösung dieser beiden Lücken verkauft werden.

Was tun, wenn der eigene Anbieter noch keinen Patch liefert?

Nach Veröffentlichung der Details muss zuerst klar sein, ob deine Konfiguration betroffen und der Angriffspfad erreichbar ist. Gibt es einen vom Hersteller belegten Workaround, prüfe ihn gegen genau diesen Pfad. Eine pauschal aktivierte WAF sagt noch nichts darüber aus, ob sie den Angriff erkennt.

Ein separat installiertes, nachweislich gefixtes PHP kann bei verzögerter Paketlieferung eine Ausweichmöglichkeit sein. Plesk unterstützt die Registrierung eigener Handler. Das braucht aber einen Test mit der Anwendung, ihren Erweiterungen und ihrer Konfiguration. Nur auf „PHP 8.5“ umzuschalten, beweist keinen Schutz; entscheidend ist der konkrete Fixstand. Die von Plesk verwalteten Dateien unter /opt/plesk/php/ würden wir dafür nicht von Hand überschreiben.

Wenn eine Installation nachweislich über einen erreichbaren Pfad angreifbar ist und weder Patch noch wirksame Zwischenlösung zur Verfügung stehen, kann eine vorübergehende Zugriffsbeschränkung oder Wartungsseite notwendig werden. Die Sperre muss vor dem verwundbaren PHP-Pfad greifen. Ein Wartungsplugin, das PHP weiterhin ausführt, erfüllt das nicht automatisch. PHP einfach aus der Webserver-Konfiguration zu entfernen, ist ebenfalls riskant, wenn anschließend Quelltext ausgeliefert wird.

Eine Abschaltung aller PHP-Websites allein aufgrund der Vorankündigung würden wir nicht empfehlen. Entscheide anhand der betroffenen Anwendungen und des belegten Angriffswegs, welche Einschränkung nötig ist.

Nach dem Update zählt der laufende Prozess

Ein Paketupdate ersetzt zunächst Dateien. Bereits laufende PHP-FPM-Prozesse, Apache-Prozesse mit PHP-Modul oder langlebige CLI-Worker müssen den gefixten Code anschließend auch verwenden. Ein neu gestartetes php -v sagt nichts über ältere Worker aus.

Plane deshalb den vom Paketlieferanten vorgesehenen Dienstneustart beziehungsweise Prozesswechsel ein und kontrolliere dessen Abschluss. Bei Containern gehört der Rollout aller Replikate dazu. Ein bloßer Container-Neustart mit demselben alten Image installiert keinen Fix. Ein Host-Reboot ist für ein reines PHP-Update normalerweise nicht erforderlich; zusätzliche Paketupdates können andere Anforderungen mitbringen.

Unsere Reihenfolge für produktive Systeme wäre:

Advisory mit Installation, Handler, Erweiterungen und erreichbaren Funktionen abgleichen.
Fixpaket oder Image aus der vorgesehenen Quelle bestätigen und den Wiederherstellungsweg prüfen.
Betroffene Instanzen aktualisieren und alte Prozesse kontrolliert ersetzen.
Kritische Anwendungsfunktionen testen, Fehlerlogs prüfen und alle Websites beziehungsweise Replikate erfassen.
Paketstand, verwendeten Handler und Zeitpunkt des Prozesswechsels dokumentieren.

Für diesen Abgleich solltest du keine öffentlich erreichbare phpinfo()-Seite dauerhaft stehen lassen. Nutze vorhandene Verwaltungsfunktionen oder einen zugriffsbeschränkten Prüfweg. Falls bereits konkrete Hinweise auf eine Kompromittierung vorliegen, reicht Patchen allein außerdem nicht: Der Fix entfernt keine zuvor abgelegten Dateien oder gestohlenen Zugangsdaten.

Bei vielen Kundenwebsites ist die Zuordnung von Anwendung, PHP-Handler und Paketquelle oft der aufwendigste Teil. Genau dort setzt ein Betriebs- und Security-Check an. Wer diese Liste vor dem Release fertig hat, kann danach gezielt handeln.

Update-Log

20.10.2026: PHP veröffentlicht die Vorankündigung des kritischen Sicherheitsreleases.
21.10.2026, 00:34 Uhr MESZ: Erste Einordnung mit Plesk-Bestandsprüfung, Updatewegen und Grenzen möglicher Härtungsmaßnahmen. Noch keine bestätigten Fixstände.
21.10.2026, 00:45 Uhr MESZ: PHP2Shell-Demo ausgewertet und über die eigene Website eingebunden. Sichtbare Codeausführung, PHP-FPM-Durchläufe und Grenzen der daraus ableitbaren Betroffenheit ergänzt.