PHP2Shell und das Ende von Legacy-PHP bei VO

Am 21. Oktober 2026 veröffentlichte das PHP-Entwicklungsteam dringende Sicherheitsupdates für zwei Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619. Beide ermöglichen die Ausführung von Code aus der Ferne: Ein Angreifer kann eigenen Code auf einem Webserver ausführen, ohne sich anzumelden oder über ein Konto auf diesem Server zu verfügen.

Was PHP2Shell (so lautet der Name für diese beiden Exploits) besonders gefährlich macht, ist der Zeitpunkt: Bereits in dem Moment, als die Sicherheitslücken bekannt wurden, wurden erste Ausnutzungsversuche beobachtet, und schon kurz darauf kursierten funktionierende Angriffstechniken.

Es gab keinen Zeitraum, in dem ein Server als sicher angesehen werden konnte, während auf einen geeigneten Wartungstermin gewartet wurde.

Die Reaktion der Sicherheitsgemeinschaft spiegelte diese Dringlichkeit wider. CERT-EU veröffentlichte den Sicherheitshinweis 2026-018, in dem die sofortige Installation von Patches oder die Isolierung betroffener Systeme empfohlen wurde. ENISA gab gemeinsam mit der Europäischen Kommission, CERT-EU, Europol und dem Europäischen CSIRT-Netzwerk eine gemeinsame Erklärung heraus, in der zu sofortigem Handeln aufgerufen wurde. Das luxemburgische CIRCL veröffentlichte die Empfehlung TR-102, in der die Einstufung als „kritisch“ bestätigt wurde. Die NSA veröffentlichte am selben Tag eine eigene Empfehlung. Links zu all diesen Dokumenten finden Sie am Ende dieses Artikels.

Die meisten Sicherheitshinweise, die Website-Betreiber erreichen, betreffen eine bestimmte Anwendung: ein WordPress-Plugin, eine Joomla-Erweiterung, ein Shopsystem. Die Lösung besteht in der Regel darin, diese eine Komponente zu aktualisieren. PHP2Shell sitzt tiefer. Die Schwachstelle liegt in der PHP-Laufzeitumgebung selbst, also der Engine, die jede PHP-Anwendung auf unseren Servern ausführt.

Eine Website kann daher auf Anwendungsebene vollständig auf dem neuesten Stand sein und dennoch anfällig sein. Eine WordPress-Seite, bei der alle Plugins aktualisiert wurden, eine Drupal-Seite mit der neuesten Version, eine maßgeschneiderte Anwendung, bei der es noch nie ein Sicherheitsproblem gab: Sie alle sind gefährdet, wenn die zugrunde liegende PHP-Version nicht gepatcht wurde.

Da wir die PHP-Versionen auf unseren Servern bereitstellen, lag es an uns, dieses Problem zu beheben, und wir konnten nicht auf die einzelnen Website-Betreiber warten. Also mussten wir handeln.

Innerhalb weniger Stunden nach Bekanntwerden der Sicherheitslücke haben wir alle unterstützten PHP-Versionen auf unseren Plesk-Servern auf die korrigierten Versionen aktualisiert. Für Kunden, die bereits eine aktuelle PHP-Version nutzten, war die Angelegenheit damit erledigt: Es änderte sich nichts, und es mussten keine weiteren Maßnahmen ergriffen werden.

Für PHP-Versionen, deren Lebenszyklus bereits abgelaufen ist, gab es keinen Patch, den man hätte anwenden können. Das PHP-Team pflegt diese Zweige nicht mehr, und für sie gibt es keine Korrektur für PHP2Shell. Jede der betroffenen Versionen war bereits seit mindestens zehn Monaten nicht mehr unterstützt. Wir hatten nur zwei Möglichkeiten: Entweder die bekannten, aktiv ausgenutzten Sicherheitslücken in unserer Infrastruktur bestehen zu lassen oder diese Versionen abzuschalten. Wir haben sie abgeschaltet.

Wir haben dies ohne Vorankündigung getan, und das war eine bewusste Entscheidung. Die Angriffe hatten bereits begonnen. Hätten wir die Deaktivierung eine Woche im Voraus angekündigt, hätte dies bedeutet, dass jede veraltete Website auf unserer Plattform eine Woche lang ein leichtes Ziel gewesen wäre und dass die Ankündigung selbst den Angreifern genau verraten hätte, wo sie suchen müssen.

Seit der Deaktivierung haben wir Anfragen erhalten, eine ältere PHP-Version für einzelne Konten wieder zu aktivieren, oft aus triftigen Gründen: eine Altanwendung, die nicht kurzfristig aktualisiert werden kann, eine Agentur, die ihren Betrieb eingestellt hat, oder eine bereits für das nächste Quartal geplante Migration. Wir haben Verständnis für jeden einzelnen dieser Gründe, lehnen jedoch alle Anfragen ab.

Der Grund dafür ist, dass sich eine Sicherheitslücke beim Shared Hosting niemals auf eine einzige Website beschränkt. Ein einziger kompromittierter PHP-Prozess auf einem Server bietet einem Angreifer einen Einstiegspunkt, von dem aus er alle anderen dort laufenden Prozesse ausloten kann. Würde man für einen Kunden eine veraltete Version weiterlaufen lassen, würde dies alle anderen Kunden auf diesem Server gefährden – auch diejenigen, die alles richtig gemacht haben.

Wir möchten auch klarstellen, was wir dabei abwägen. Eine Website, die vorübergehend nicht erreichbar ist, weil ein PHP-Update erforderlich ist, stellt eine Unannehmlichkeit dar, für die es eine bekannte Lösung gibt. Eine gehackte Website kann hingegen gestohlene Kundendaten, verunstaltete Seiten, die Verbreitung von Malware an Besucher, die Aufnahme in die Blacklist von Suchmaschinen und – gemäß DSGVO – eine meldepflichtige Datenschutzverletzung bedeuten. Wenn wir zwischen diesen beiden Optionen wählen müssen, entscheiden wir uns jedes Mal für die Unannehmlichkeit.

Dies gilt auch für die Zukunft. Wir werden PHP-Versionen, deren Lebenszyklus abgelaufen ist, nicht länger auf unserer Plattform zur Verfügung stellen. Zwar gibt es für einige alte Zweige erweiterte Sicherheitspflege durch Dritte, doch bietet diese nicht dieselben Garantien wie eine offiziell unterstützte Version, und PHP2Shell hat gezeigt, wie schnell eine nicht gepatchte Laufzeitumgebung zu einem Sicherheitsrisiko wird.

Falls Ihre Website am oder nach dem 21. Oktober nicht mehr funktioniert, läuft sie höchstwahrscheinlich mit einer deaktivierten PHP-Version. Um das Problem zu beheben, müssen Sie auf eine unterstützte Version umstellen. Gehen Sie in Plesk zu „Websites & Domains“, öffnen Sie die PHP-Einstellungen für die Domain und wählen Sie eine Version aus der untenstehenden Liste aus.

• PHP 8.5 (8.5.12 oder neuer): unterstützt, empfohlen
• PHP 8.4 (8.4.27 oder neuer): unterstützt, empfohlen
• PHP 8.3 (8.3.36 oder neuer): unterstützt, empfohlen
• PHP 8.2 (8.2.35 oder neuer): wird bis Dezember 2026 unterstützt
• PHP 8.1 und älter: deaktiviert, es gibt keine sichere Version

Zwei Dinge, die man beachten sollte:

• PHP 8.2 ist nur eine kurzfristige Lösung. Der offizielle Sicherheitssupport endet im Dezember 2026; danach wird es das gleiche Schicksal ereilen wie 8.1. Falls 8.2 derzeit die einzige Version ist, auf der Ihre Website läuft, betrachten Sie sie als Zwischenlösung und planen Sie schon jetzt den Umstieg auf 8.3 oder eine neuere Version.
• Ein reiner Versionswechsel reicht möglicherweise nicht aus. Wenn Ihre Website unter einer neueren PHP-Version nicht mehr funktioniert, liegt die Ursache in der Regel in einem veralteten CMS-Kern, Theme oder Plugin oder in benutzerdefiniertem Code, der Funktionen nutzt, die in PHP 8 entfernt wurden. In diesem Fall muss die Anwendung selbst aktualisiert werden. Bei WordPress, Joomla und Drupal bedeutet dies in der Regel, den Kern und alle Erweiterungen zu aktualisieren; bei benutzerdefinierten Anwendungen muss ein Entwickler den Code überprüfen.

PHP2Shell wird nicht die letzte Sicherheitslücke dieser Art sein. Das PHP-Projekt veröffentlicht für jede Version einen klaren Support-Zeitplan, und das Muster ist immer dasselbe: Ein Zweig erhält zwei Jahre lang aktiven Support und weitere zwei Jahre lang Sicherheitspatches, danach nichts mehr. Websites, die innerhalb dieses Zeitraums liegen, erhalten innerhalb weniger Stunden nach Bekanntwerden eines Problems Korrekturen. Websites außerhalb dieses Zeitraums erhalten diese nicht, und die Kluft zwischen beiden war noch nie so deutlich zu erkennen wie in dieser Woche.

Unsere Empfehlung ist einfach: Verwenden Sie für Ihre Website eine PHP-Version, für die weiterhin Sicherheitsupdates bereitgestellt werden, betrachten Sie das Upgrade auf die nächste Version eher als routinemäßige Wartungsmaßnahme denn als Projekt und halten Sie Ihr CMS, Ihre Themes und Plugins auf dem neuesten Stand, damit das Upgrade reibungslos verläuft. Wir werden weiterhin alle derzeit unterstützten PHP-Zweige anbieten, jedoch keine Versionen mehr, deren Support offiziell eingestellt wurde.

• PHP – Sicherheitsmitteilung vom 21. Oktober 2026
• CERT-EU – Sicherheitshinweis 2026-018
• ENISA – Gemeinsame Erklärung zu kritischen PHP-Sicherheitslücken
• CIRCL Luxemburg – TR-102
• NSA – Hinweis zu PHP-Updates