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-Kunden 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. Jede einzelne Website wurde anschließend geprüft. Um 16 Uhr erschien der offizielle Patch, rund anderthalb Stunden später lief er auf allen unseren Servern.
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 laufen, 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: Wir haben durch Anpassung in der .htaccess-Datei (das ist im Prinzip eine Textdatei, in der man pro Datei-Ordner zusätzliche Serverkonfigurationen angeben kann) den Angriffsvektor minimiert. Doch den Kernschutz, das eigentliche Update, können wir in solchen Fällen nicht selbst installieren.
Für Website-Support zahlt man nicht für den Alltag, bei dem die Maschinen schnurren, sondern für die wenigen Stunden, in denen einem alles um die Ohren fliegt! Sie wissen nicht, wer Ihren Server betreut? Sprechen Sie uns an.