PHP2Shell: Panik und offline? Warum eigentlich?

PHP2Shell: Regierungen, Krankenhäuser und Hoster ziehen den Stecker. Dabei müsste ein großer Teil dieser Seiten gar nicht offline gehen.

Seit dem 21. Oktober hat PHP ein Problem mit Namen: PHP2Shell. Zwei kritische Lücken im Kern der Sprache (CVE-2026-109618 und CVE-2026-109619, CVSS 9.2), und rund 69 Prozent aller Websites laufen auf PHP.

Die Reaktion war und ist vielerorts: abschalten. Regierungsseiten, Krankenhäuser, Nachrichtenportale, Hoster. Seiten gehen freiwillig vom Netz, weil ein Angriff ohne Login möglich ist, bevor überhaupt Anwendungscode läuft. Das Patchen selbst wird zum Ausfall.

Dazu kommt ein Netz voller Lärm: KI-generierte „Analysen“, dubiose Scanner, zehn Varianten derselben drei Absätze. Zwischen echter CERT-Warnung und SEO-Müll zu unterscheiden ist schwierig.

Kaum jemand stellt die Frage, die sich aufdrängt: Muss eine Seite dafür überhaupt offline gehen?

Für einen großen Teil der betroffenen Seiten: eigentlich nicht. Wer eine PHP-Seite in festen Intervallen abruft und das Ergebnis statisch über HTTPS ausliefert, nimmt den verwundbaren PHP-Prozess aus dem öffentlichen Zugriff. Der Besucher sieht die Seite, der Angreifer findet kein erreichbares PHP mehr. Das funktioniert für wohl den größten Teil publizierende Seiten ohne Live-Interaktion: WordPress, Drupal, Joomla, Firmenseiten, Blogs etc. als Schaufenster. Sie zeigen Inhalte, sie verarbeiten nichts.

Genau so eine vorgeschaltete Auslieferung bieten wir an: ein Mirror, fest an eine IP gebunden, der die Seite in festen Intervallen abruft und statisch und sicher bereitstellt. Das PHP dahinter ist damit aus dem Netz. Der Sicherheitsgewinn liegt genau darin: Das PHP ist wirklich vom allgemeinen öffentlichen Netz getrennt. Genau das leistet unsere vorgeschaltete Lösung.

Bleibt die eigentliche Frage. Warum ist Abschalten der Reflex und nicht die generelle Absicherung? Vielleicht, weil das Absichern der eigenen Architektur die Einsicht verlangt, dass der bisherige Weg jahrelang ein unnötiges Risiko war? Oder, weil der Aufwand für eine Änderung so hoch ist.

Bei uns stimmt das nicht. Der Wechsel ist in der Regel in unter einer Stunde erledigt, im Wesentlichen die Zeit, die die DNS-Umstellung braucht. Firewall davor, DNS umgelegt, Zertifikat installiert, fertig.

Das Fenster zwischen Veröffentlichung einer Lücke und erstem Angriff lag diesmal bei Stunden. Eine Stunde Umstellung schlägt dann Tage im Wartungsmodus.

Die nächste PHP-Lücke kommt. Die Frage ist, ob dann wieder der Stecker gezogen wird, oder ob die Seiten, die ohnehin nur senden, längst so ausgeliefert werden, dass ein PHP-Bug sie gar nicht erreicht.