php2shell aus Sicht eines Hosters: Ruhe bewahren, aber nicht verschlafen

Manuel Schmitt ist iX-Autor sowie Gründer und CTO der manitu GmbH. Er berichtet von seinen Erfahrungen als Hostinganbieter mit den php2shell-Lücken.

In diesem 2,5-stündigen iX-Webinar für PHP-Entwickler und Webmaster erklärt PHPUnit-Erfinder Sebastian Bergmann, wie man ältere PHP-Versionen absichert, warum jetzt ein Upgrade auf eine aktuelle PHP-Version unvermeidbar ist und welche Stolpersteine man dabei vermeiden muss. Webinar: Vom Notfallpatch zum Upgrade – PHP nach PHP2Shell, 6.11.2026, 9:30-12:00

Dank KI sehen wir uns als Hoster nicht nur neuen Herausforderungen gegenüber, sondern auch immer öfter auftretenden Sicherheitslücken. Manchmal tauchen mehrmals pro Woche relevante CVEs für alles auf, was für uns im Hoster-Alltag eine Rolle spielt – mal dringender, mal weniger.

Sobald das Kürzel RCE (Remote Code Execution) auftaucht, schrillen natürlich bei jedem die Alarmglocken. Ob ein Kernel-Root-Exploit oder (wie in der Woche mit den php2shell-Lücken) ein fundamentaler Fehler im Speicher-Management von PHP: Verständlicherweise reagiert man mit dem Reflex, sofort alles abzuschalten, wie wir es auch bei Marktbegleitern gesehen haben. Wir hatten uns bewusst dagegen entschieden.

Manuel Schmitt ist Gründer und CTO der manitu GmbH.

In diesem 2,5-stündigen iX-Webinar für PHP-Entwickler und Webmaster erklärt PHPUnit-Erfinder Sebastian Bergmann, wie man ältere PHP-Versionen absichert, warum jetzt ein Upgrade auf eine aktuelle PHP-Version unvermeidbar ist und welche Stolpersteine man dabei vermeiden muss. Webinar: Vom Notfallpatch zum Upgrade – PHP nach PHP2Shell, 6.11.2026, 9:30-12:00

Was wirklich passiert war

Die Ankündigung kursierte noch vor den offiziellen Details, und das ließ wenig Gutes erahnen. Keine triviale Lücke, die nur unter ungünstigen Konstellationen ausnutzbar wäre, sondern ein Angriff, der die gesamte PHP-basierte Webserverwelt betraf. Wer PHP und RCE in einem Satz liest, denkt unwillkürlich an die (zum Glück längst vergangenen) Zeiten, in denen PHP als unsichere Sprache verschrien war. Derartige Klassen von Schwachstellen werden nach meiner Einschätzung allmählich fast überall entdeckt werden. PHP ist hierbei weder eine rühmliche noch eine besonders unrühmliche Ausnahme.

Was die Lücke technisch so bedeutsam machte: Es war kein isolierter Bug in einer einzelnen Funktion, sondern ein strukturelles Problem im Umgang mit Speicherfehlern, das sich durch den gesamten PHP-Kern zog. Der offizielle Patch änderte schließlich 389 Dateien. Zwei Jahrzehnte hatte dieser Fehler also in den meisten PHP-Versionen geschlummert.

Die Entscheidung: Gegenmaßnahmen statt Abschaltung

Für uns als Hoster ist eine solche Situation – neben Kernel-Exploits – einer der denkbar kritischsten Fälle. Dennoch haben wir seit dem ersten Hinweis, dass da etwas im Kommen war, die Situation mit Ruhe und Sorgfalt beobachtet. Wir nutzten offizielle Quellen, eigene Analyse und die uns zur Verfügung stehenden Quellen. Wir sind gut vernetzt, jeder bei uns im Team verfügt über hilfreiche Kontakte, und dies alles hilft, frühzeitig reagieren zu können.

Wir haben diesen Weg gewählt, als sich abzeichnete, dass eine Mitigation möglich war – noch vor der offiziellen Veröffentlichung der Sicherheitslücken. Die Abwägung war nicht trivial: Sicherheit unserer Systeme auf der einen Seite, Verfügbarkeit der Kunden-Anwendungen auf der anderen. Die Mitigation bedeutete unter anderem, dass Formular-Uploads (teils auch unabhängig von PHP) nicht mehr funktionierten – mit unangenehmen Folgen für Kunden. Das betraf auch unsere eigene Website und unser Kundenportal. Diesen Kompromiss haben wir mit fortlaufender Analyse und noch stärkerer Überwachung unserer Systeme abgesichert, denn eine Mitigation allein reicht bei solch einem Szenario nicht – man muss noch wachsamer sein als sonst.

Selbstverständlich lag auch die Alternative auf dem Tisch, vorsorglich PHP oder gar „alles mit Web“ abzuschalten. Sie war als Fallback eingeplant. Wir haben diese Karte nicht gezogen, weil unsere Einschätzung war, dass die Mitigation hält. Diese Einschätzung erwies sich im Nachgang als richtig.

Das Update: Vorbereitung macht den Unterschied

Als die offiziellen Patches erschienen, war die Erleichterung spürbar: weil das Problem gelöst war und endlich Patches vorhanden, aber auch, weil die technischen Details unsere Einschätzung der Mitigation und deren Wirksamkeit bestätigten.

Wir setzen auf Gentoo Linux, was bedeutet: kein einfaches apt upgrade, sondern ein eigener Build-, Prüf- und Deployment-Prozess. Das klingt aufwendiger, gibt uns aber auch deutlich mehr Kontrolle. Die Updates liefen durch wie bei einem normalen PHP-Patch-Release, aber mit einer Extra-Portion Aufmerksamkeit dafür, dass wirklich alle betroffenen Systeme das Update erhalten und angewandt haben. Automatismen sind gut – ein zusätzlicher prüfender Blick war in diesem Fall keine Kür, sondern Pflicht. Die Nacht danach verlief ruhig. Fast zu ruhig – man wartet in solchen Momenten fast darauf, dass jemand innerhalb weniger Stunden eine Regression findet.

Was wir daraus mitnehmen

Drei Dinge haben sich bei diesem Vorfall für uns bestätigt.

Erstens: Agieren, aber eben nicht überreagieren. Sicherheitsrelevante Themen verlangen höchste Priorität, aber kein übereifriges Handeln. Ja, das kann schiefgehen. Und wir sagen auch ehrlich: Man kann nicht immer PHP abschalten, nur weil jemand PHP und RCE irgendwo im Netz in einem Satz schreibt. Das müsste man dann konsequenterweise bei jeder Kombination aus beliebigem Produkt-Namen und RCE immer so machen. Wir wurden in diesem Vorfall in unserer Haltung bestärkt, dass Ruhe und technischer Sachverstand mehr wert sind als reflexartiges Handeln – auch wenn ersteres manchmal schwerer zu vermitteln ist.

Zweitens: Eine gute Status-Seite ist Gold wert. Mehr Kunden als je zuvor haben in dieser Situation aktiv unsere Status-Seite besucht und sich primär dort informiert, auch über unsere laufenden Aktualisierungen. Bemerkenswerterweise haben sie danach den Support deutlich seltener kontaktiert als bei weniger kritischen Vorfällen. Wir glauben, dass unsere Kunden hier ganz bewusst die Status-Seite als ihre primäre Quelle genutzt haben – und dass informierte Kunden, die sehen, dass man sich kümmert, wie erhofft ruhiger reagieren.

Drittens: Manchmal ist keine Mail auch eine gute Kommunikation. Wir haben in diesem Fall entgegen unserer sonstigen Praxis bewusst auf ein Mailing an Kunden verzichtet. Das war eine der schwierigsten Entscheidungen in diesem Vorfall, denn normalerweise pflegen wir eine proaktive Kommunikation. Aber wir wollten schlichtweg keine unnötige Panik schüren. Gerade unbedarfte Kunden hätten viele noch so wohlbedachte Worte vielleicht missverstehen können. Wir kümmerten uns um die Angelegenheit, auch wenn wir in diesem Fall nicht laut darüber sprachen. Im Rückblick zeigte sich, dass die erhoffte Wirkung eintrat: Kunden lasen unsere Status-Seite und die FAQ, einige meldeten sich und bedankten sich explizit für genau diese Vorgehensweise.