Am 21. Oktober 2026 hat das PHP-Team zwei schwere Sicherheitsl\u00fccken geschlossen. PHP ist die Technik, auf der WordPress und ein Gro\u00dfteil aller Websites laufen. \u00dcber die L\u00fccken, inzwischen unter dem Namen \u201ephp2shell\u201c bekannt, konnten Angreifer ohne Passwort fremden Code auf einem Webserver ausf\u00fchren. Das Besondere: Details dazu waren schon einen Tag vor dem offiziellen Update an die \u00d6ffentlichkeit gelangt.<\/p>\n\n\n\n
Jede Anfrage an eine Website, etwa ein ausgef\u00fclltes Kontaktformular oder ein hochgeladenes Bild, wird zuerst von der darunter liegenden Software PHP verarbeitet, bevor WordPress oder die eigentliche Website sie \u00fcberhaupt zu sehen bekommt. Genau in diesem ersten Verarbeitungsschritt steckten die beiden Fehler. Ein Angreifer musste nur ein speziell pr\u00e4pariertes Formular an eine Website schicken. Bei der ersten L\u00fccke, CVE-2026-109618<\/a>, f\u00fchrte das dazu, dass PHP der Arbeitsspeicher ausging, w\u00e4hrend die Daten noch nicht vollst\u00e4ndig eingelesen waren, und PHP die unvollst\u00e4ndigen Daten anschlie\u00dfend f\u00fcr g\u00fcltig hielt. Bei der zweiten L\u00fccke, CVE-2026-109619<\/a>, blieben Reste einer fr\u00fcheren Anfrage im Speicher zur\u00fcck und wurden bei der n\u00e4chsten Anfrage versehentlich weiterverwendet. In beiden F\u00e4llen konnte der Angreifer so eigene Befehle auf dem Server ausf\u00fchren lassen, ohne Passwort und ohne dass die Website selbst etwas davon bemerkt. Im schlimmsten Fall h\u00e4tte er damit Daten auslesen, Inhalte ver\u00e4ndern oder den Server f\u00fcr weitere Angriffe missbrauchen k\u00f6nnen. Betroffen war praktisch jede Website, die PHP nutzt, ganz gleich ob WordPress, SaaS-Anwendung, Onlineshop oder Vereinsseite.<\/p>\n\n\n\n Der australische Sicherheitsexperte Mathew Clark hat in seinem Blog \u201eSecure in Seconds\u201c beschrieben, was diesen Fall so ungew\u00f6hnlich macht. Fr\u00fcher vergingen zwischen der Ver\u00f6ffentlichung eines Updates und den ersten Angriffswellen oft Wochen. Diesmal rechneten Fachleute damit, dass massenhafte Angriffe nur etwa 15 Minuten<\/strong> nach dem Update beginnen. Wer erst reagiert, wenn das Update erscheint, ist also schon zu sp\u00e4t. Entscheidend ist, vorher vorbereitet zu sein.<\/p>\n\n\n\n Clark betont au\u00dferdem: Die L\u00fccke steckt nicht in WordPress oder einem Plugin, sondern eine Ebene darunter, auf dem Server<\/strong>. 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\u00fcr die Serverwartung zust\u00e4ndig?<\/strong> Wer das nicht in einer Minute beantworten kann, hat ein echtes Risiko. <\/p>\n\n\n\n Besonders gef\u00e4hrdet sind Websites auf alten PHP-Versionen, denn f\u00fcr sie gibt es gar kein offizielles Update mehr.<\/p>\n\n\n\nSicherheitsl\u00fccken sind nichts ungew\u00f6hnliches, warum war es diesmal anders?<\/h2>\n\n\n\n
So lief der Tag bei uns<\/h2>\n\n\n\n