PHP2Shell: Kritische PHP-Sicherheitslücken – was Betreiber jetzt tun müssen

Was ist passiert?

Das PHP-Projekt hat am 21. Oktober 2026 zwei kritische Schwachstellen veröffentlicht. Fehler bei der Verwaltung von internem Speicher und requestgebundenen Daten können unter bestimmten Bedingungen die nicht authentifizierte Ausführung von Code auslösen.

Die offiziellen PHP-Advisories benennen CVE-2026-109618 (Speicherzustand bei Out-of-Memory-Situationen) und CVE-2026-109619 (veralteter globaler Zustand). Es handelt sich um Fehler in der PHP-Laufzeit – nicht um einen gewöhnlichen Bug in einer bestimmten Website.

Wer ist betroffen?

Das PHP-Projekt warnt ausdrücklich vor Installationen, die Webanfragen bedienen. Zu den genannten Betriebsarten gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Für mod_php wurde ein besonders kritischer Angriffsweg beschrieben.

Entscheidend ist die tatsächlich vom Webserver benutzte PHP-Laufzeit. Der Befehl php -v in der Shell kann eine andere Version zeigen als die PHP-Version einer Domain. Bei mehreren Domains oder PHP-Handlern jeden genutzten Handler gesondert prüfen.

Was ist bei Plesk besonders wichtig?

Plesk bestätigt, dass auch die mit Plesk ausgelieferten PHP-Versionen betroffen sind. In Plesk müssen die verwendeten PHP-Handler der Domains und die von Plesk bereitgestellten Updates geprüft werden.

Bei älteren PHP-Zweigen außerhalb des regulären PHP-Supports nennt Plesk teilweise distributionsspezifisch neu gebaute Pakete mit gleicher Versionsnummer. Hier reicht die reine Versionsnummer nicht aus: Veröffentlichungsdatum und Paketstand des Hosting-Anbieters sind entscheidend. Mittel- und langfristig sollten veraltete Zweige ersetzt werden.

Was sollten Unternehmen jetzt konkret tun?

1. PHP-Handler und alle produktiv verwendeten Versionen im Hosting-Panel erfassen. 2. Sicherstellen, dass ein aktuelles Backup existiert und die Wiederherstellung möglich ist. 3. Die vom Anbieter bereitgestellten Sicherheitsupdates für jede betroffene PHP-Laufzeit installieren. 4. Plesk- und Betriebssystem-Updates sowie die verwendeten PHP-Builds prüfen. 5. Danach Funktionstests der Anwendungen durchführen und verdächtige Ereignisse in Logs prüfen.

Das PHP-Projekt betont, dass es keine vollständigen Workarounds gibt. Ein WAF oder eine Konfigurationsänderung darf das eigentliche Sicherheitsupdate nicht ersetzen. Bei Verdacht auf Kompromittierung sollte eine fachkundige Incident-Response-Prüfung erfolgen.

Was wir nicht behaupten können

Ohne Einblick in die Serverkonfiguration und die eingesetzten Pakete kann niemand seriös aus einer öffentlichen Website ableiten, ob sie von PHP2Shell betroffen ist oder bereits ausgenutzt wurde. Ein kostenloser Website-Performance-Check ersetzt daher keinen Sicherheitscheck.