Am 21. Oktober 2026 hat das PHP-Team zwei schwere Sicherheitslücken geschlossen. PHP ist die Technik, auf der WordPress und ein Großteil aller Websites laufen. Über die Lücken, inzwischen unter dem Namen „php2shell“ bekannt, konnten Angreifer ohne Passwort fremden Code auf einem Webserver ausführen. Das Besondere: Details dazu waren schon einen Tag vor dem offiziellen Update an die Öffentlichkeit gelangt.
Hintergrund der Sicherheitslücken
Jede Anfrage an eine Website, etwa ein ausgefülltes Kontaktformular oder ein hochgeladenes Bild, wird zuerst von der darunter liegenden Software PHP verarbeitet, bevor WordPress oder die eigentliche Website sie überhaupt zu sehen bekommt. Genau in diesem ersten Verarbeitungsschritt steckten die beiden Fehler. Ein Angreifer musste nur ein speziell präpariertes Formular an eine Website schicken. Bei der ersten Lücke, CVE-2026-109618, führte das dazu, dass PHP der Arbeitsspeicher ausging, während die Daten noch nicht vollständig eingelesen waren, und PHP die unvollständigen Daten anschließend für gültig hielt. Bei der zweiten Lücke, CVE-2026-109619, blieben Reste einer früheren Anfrage im Speicher zurück und wurden bei der nächsten Anfrage versehentlich weiterverwendet. In beiden Fällen konnte der Angreifer so eigene Befehle auf dem Server ausführen lassen, ohne Passwort und ohne dass die Website selbst etwas davon bemerkt. Im schlimmsten Fall hätte er damit Daten auslesen, Inhalte verändern oder den Server für weitere Angriffe missbrauchen können. Betroffen war praktisch jede Website, die PHP nutzt, ganz gleich ob WordPress, SaaS-Anwendung, Onlineshop oder Vereinsseite.
Sicherheitslücken sind nichts ungewöhnliches, warum war es diesmal anders?
Der australische Sicherheitsexperte Mathew Clark hat in seinem Blog „Secure in Seconds“ beschrieben, was diesen Fall so ungewöhnlich macht. Früher vergingen zwischen der Veröffentlichung eines Updates und den ersten Angriffswellen oft Wochen. Diesmal rechneten Fachleute damit, dass massenhafte Angriffe nur etwa 15 Minuten nach dem Update beginnen. Wer erst reagiert, wenn das Update erscheint, ist also schon zu spät. Entscheidend ist, vorher vorbereitet zu sein.
Clark betont außerdem: Die Lücke steckt nicht in WordPress oder einem Plugin, sondern eine Ebene darunter, auf dem Server. Ein Plugin-Update hilft deshalb nicht. Beheben kann das Problem nur, wer den Server verwaltet. Seine wichtigste Frage an jedes Unternehmen lautet daher: Wer ist bei uns eigentlich für die Serverwartung zuständig? Wer das nicht in einer Minute beantworten kann, hat ein echtes Risiko.
Besonders gefährdet sind Websites auf alten PHP-Versionen, denn für sie gibt es gar kein offizielles Update mehr.
So lief der Tag bei uns
Für unsere RundUmsorgt Customers war die Frage nach der Zuständigkeit schnell beantwortet: Das sind wir. Noch am Vormittag haben wir auf unseren Servern Schutzmaßnahmen eingerichtet, die den bekannten Angriffsweg blockiert haben, rund sechs Stunden bevor das offizielle Update erschien. Jede einzelne Website haben wir anschließend geprüft. Nach ca. 6 Stunden war dann der Patch verfügbar und wir konnten die Sicherheits-Updates auf unseren Servern einspielen.
Bei den Shared Hostern ohne Betreuung aus sieht es anders aus. Da wir dort nicht an die Technik herankommen, um Sicherheits-Patches einzuspielen, müssen Website-Betreiber warten, bis der jeweilige Anbieter tätig wird.
Bei einem der großen Anbieter, bei dem einige Kundenwebsites laufenn, die nicht bei uns sind, stand der Patch am Abend (21.10.26 Stand 21:00 Uhr) noch aus. Wo wir Zugriff hatten, haben wir auch dort die wichtigsten Schutzmaßnahmen gesetzt. Doch der Kernschutz, das eigentliche Update, können wir in solchen Fällen nicht selbst installieren.
Wie ich immer sage: Für Website-Support zahlt man nicht für den langweiligen Alltag, bei dem alles läuft, sondern für die wenigen Stunden, in denen alles explodiert!