Eine unerwartet an die Öffentlichkeit gelangte Sicherheitslücke in der weltweit meistgenutzten Web-Programmiersprache PHP hat die globale IT-Branche am Mittwoch in akute Alarmbereitschaft versetzt. Unter dem Namen „PHP2Shell“ bedrohen zwei Schwachstellen im Kern des PHP-Interpreters (CVE-2026-109618 und CVE-2026-109619) Millionen von Internetseiten, Onlineshops und Regierungsportale. Weil technische Details und erste Funktionstests (Proofs-of-Concept) vorab im Internet geleakt wurden, zog das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Alarmstufe auf die zweithöchste Stufe „Orange“ hoch und riet Betreibern im Zweifel, Server sofort vom Netz zu trennen.
Kommunen im Blackout, Entwarnung für LiteSpeed-Nutzer
In Deutschland reagierten Behörden und öffentliche Einrichtungen drastisch: Mehrere Städte wie Mainz, Potsdam und Halberstadt schalteten ihre Webportale vorsorglich komplett ab. Auch Universitäten und die Berliner Universitätsklinik Charité gingen zeitweise vom Netz, um eine Kompromittierung zu verhindern. Die Lücken weisen einen kritischen Schweregrad von 9,2 von 10 Punkten auf der CVSS-Skala auf und ermöglichen es Angreifern, ohne jede Anmeldung Schadcode aus der Ferne auszuführen (Remote Code Execution).
Während Administratoren von Apache-Servern (vor allem beim Einsatz des veralteten Moduls mod_php) und PHP-FPM-Infrastrukturen unter extremem Zeitdruck Notfall-Patches einspielen mussten, atmeten Betreiber von Systemen auf Basis von LiteSpeed-Webservern auf. Branchenanalysen und Sicherheitsberichte am Tag nach der Panik zeigten, dass LiteSpeed-Umgebungen von der unmittelbaren Bedrohungswelle weitgehend isoliert waren.
Warum LiteSpeed-Server der Panik entgingen
Sicherheitsexperten führen die Immunität beziehungsweise das minimale Risiko von LiteSpeed-Architekturen auf fundamentale Unterschiede in der Verarbeitung von Web-Anfragen zurück:
- Abweichende Request-Architektur: Die Kernschwachstellen bei „PHP2Shell“ basieren auf Fehlern bei der Speicherbereinigung, wenn HTTP-Anfragen das konfigurierte Limit überschreiten und einen Out-of-Memory-Absturz (OOM) des PHP-Prozesses erzwingen. LiteSpeed verwendet für die PHP-Anbindung die hauseigene LSAPI (LiteSpeed Server Application Program Interface). Diese verarbeitet und filtert Datenströme grundlegend anders als der klassische Apache-Webserver. Ein gezieltes Auslösen des korrupten Speicherzustands über den HTTP-Header schlug in Testumgebungen fehl.
- Keine Angriffsfläche vor dem Anwendungscode: Während die Bedrohung bei Apache-Konfigurationen so fatal ist, weil der Angriff greift, noch bevor jeglicher WordPress- oder Anwendungscode ausgeführt wird, kapselt LiteSpeed die PHP-Worker strenger ab. Zirkulierende Exploits waren spezifisch darauf ausgelegt, Schwächen in Apache- oder FPM-Prozessstrukturen auszunutzen, liefen bei LiteSpeed jedoch ins Leere.
- Strikte Nutzer-Isolierung im Shared Hosting: Viele moderne Hosting-Plattformen, die auf LiteSpeed setzen, betreiben jede Webseite standardmäßig in einer stark reglementierten, isolierten Systemumgebung (CloudLinux/CageFS). Selbst im hypothetischen Fall einer Ausnutzung wäre der Angreifer in einem virtuellen Käfig gefangen gewesen, ohne Zugriff auf den Hauptserver oder benachbarte Webseiten zu erhalten.
Nur Updates bieten dauerhafte Sicherheit
Trotz der strukturellen Vorteile von LiteSpeed betonen Sicherheitsbehörden wie das BSI und die US-Cybersicherheitsbehörde (CISA), dass Webmaster keine falsche Sicherheit walten lassen dürfen. Da es sich um Fehler direkt im Kern der Programmiersprache PHP handelt, gibt es keine verlässlichen Konfigurationsänderungen (Workarounds), die einen Angriff dauerhaft blockieren.
Die Entwickler der PHP Foundation haben inzwischen offizielle Sicherheitsupdates für alle unterstützten Versionen bereitgestellt (PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12). Administratoren weltweit sind aufgerufen, diese Updates unverzüglich einzuspielen und die betroffenen Serverdienste neu zu starten.
