// HEISE ONLINE — CYBERSECURITY
php2shell aus Sicht eines Hosters: Ruhe bewahren, aber nicht verschlafen
Die gravierenden php2shell-Sicherheitslücken zwangen Hostinganbieter zum Handeln. Das stellt die Update-Prozeduren auf die Probe – und die Kundenkommunikation.
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
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.
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.