Sicherheit: Eine KI hat in 7 von 10 Websites eine Sicherheitslücke gefunden, ist deine Website sicher?

Diese Woche haben sich Websites der niederländischen und der finnischen Regierung selbst vom Netz genommen. Kein Hacker im Serverraum, kein Ausfall: eine absichtlich getroffene Entscheidung, bis ein Patch bereitsteht. Das Forum von GrapheneOS (eine Android-Version für Datenschutzfreaks), Pinboard (ein Dienst zum Ordnen seiner Lesezeichen) und ein Teil der OBS-Website (die Software, mit der alle Streamer ihren Bildschirm aufnehmen) haben dasselbe getan. Das CERT-EU, das Team, das über die IT-Sicherheit der europäischen Institutionen wacht, empfahl sogar, alles abzuschalten, was man nicht sofort aktualisieren konnte. Das alles wegen zweier Sicherheitslücken in PHP. Und diese beiden Sicherheitslücken haben KIs gefunden.

Was ist PHP, und warum sind alle aufgeschreckt

PHP ist der Motor, der die Seiten eines großen Teils der Websites erzeugt. Wenn du den Blog deiner Bäckerin, den Onlineshop der Werkstatt um die Ecke oder eine Wikipedia-Seite öffnest, ist die Wahrscheinlichkeit groß, dass gerade ein PHP-Programm die Seite dynamisch erzeugt, nur für dich. WordPress, Drupal und Joomla, die drei großen Programme, mit denen man Websites erstellen kann, ohne Entwickler zu sein, laufen alle darauf. Wiz, das Sicherheitsunternehmen, das die Sache am 21. Oktober öffentlich gemacht hat, schätzt, dass PHP weltweit sieben von zehn Websites antreibt. Das ist ihre Zahl, aber alle Erhebungen landen ungefähr in diesem Bereich.

Und das Problem steckt in PHP selbst, nicht in einem Modul, das du vergessen hast zu aktualisieren. Laut der Analyse von Wiz sind alle Versionen aus dem letzten Jahrzehnt von mindestens einer der beiden Sicherheitslücken betroffen, und sogar eine Seite, die nur « bonjour » anzeigt, kann ausreichen. Den Forschern ist es gelungen, die vollständige Kontrolle über Server unter WordPress, Drupal und Joomla zu übernehmen, ohne Passwort und ohne Konto. Sie haben das PHP2Shell genannt: « von PHP zur Kommandozeile », also von der Webseite zu den uneingeschränkten Rechten auf der Maschine.

Der Sicherheitsverantwortliche der PHP Foundation, Volker Dusch, sagte dem Wall Street Journal, dass es das schwerwiegendste Problem sei, das PHP seit mehr als zehn Jahren erlebt habe. Er verglich es mit Heartbleed, der Sicherheitslücke von 2014, die Millionen Menschen dazu gebracht hatte, ihre Passwörter zu ändern. Das gibt den Ton an!

Die Garderobe, die dir den Mantel eines anderen zurückgibt

Stell dir die Garderobe eines Theaters vor. Der Garderobier nimmt die Mäntel entgegen, hängt jeden an einen nummerierten Haken und gibt dir eine Marke. Ganz normal.

Jetzt ist an einem Abend mit großem Andrang der Garderobier überfordert. Er räumt einen Haken, um Platz zu schaffen, aber er vergisst, die Nummer in seinem Notizbuch durchzustreichen. Der nächste Kunde kommt mit einer gut ausgewählten Marke, der Garderobier schaut in sein Notizbuch und reicht ihm, was am Haken hängt: den Mantel eines anderen, mit seinen Schlüsseln und seiner Brieftasche in der Tasche.

Die Marke stimmt nicht, aber das Notizbuch sagt ja

Genau das passiert in PHP. Wenn einem Server mitten bei der Arbeit der Speicher ausgeht, gibt PHP eine Speicherstelle frei, behält aber eine kleine Notiz, die weiterhin auf sie zeigt. Die nächste Anfrage, die von irgendwem im Internet kommen kann, stößt auf diese veraltete Notiz. Je nachdem, wie sie dabei vorgeht, kann sie lesen, was der vorherige Besucher hinterlassen hatte (den Mantel eines anderen), oder ihre eigenen Anweisungen in die Speicherstelle schieben, damit der Server sie ausführt (eine falsche Marke ins Notizbuch schieben). Und um das Chaos in der Garderobe zu verursachen, reicht es, dem Server eine etwas zu große Sendung zu schicken. Bumm.

Wer sie gefunden hat: KIs und Menschen, die wussten, wo sie suchen mussten

Hier wird die Geschichte wirklich interessant. Im August sind zwei Teams darauf gestoßen, jedes auf eigene Faust. Zuerst Calif, ein Team, das dafür bezahlt wird, Software vor den echten Hackern anzugreifen und den PHP-Code mit GPT-5.6 Sol, einem Modell von OpenAI, prüfte. Das Audit wurde von OpenAI im Rahmen eines Programms bezahlt, das Patch the Planet (« den Planeten zusammenflicken ») heißt. Danach Wiz, das heute zu Google gehört, mit seinem eigenen Tool und zwei Modellen: Googles Gemini 4 Argon und erneut GPT-5.6 Sol.

Zwei Monate lang geheim halten, und am Vortag sickert es durch

Was mir gefällt, ist, dass niemand erzählt, die KI habe alles ganz allein gemacht. Wiz erklärt, dass die Modelle vor allem dazu dienten, eine Entdeckung in einen Angriff zu verwandeln, der wirklich funktioniert: die Falle an jede PHP-Version anpassen, verstehen, warum ein Versuch scheiterte, es noch einmal versuchen. Diese Art von Kleinarbeit dauerte früher Monate. Laut Wiz hat ein einziger Forscher das in einer Woche geschafft. Und Calif betont seinerseits: Sie haben Modelle verwendet, die jeder kaufen kann, ohne spezielles Werkzeug, und was am meisten gezählt hat, war, die Geschichte von PHP und seine alten Bugs zu kennen. Ihr Satz auf Französisch: „kein Modell fördert mit einfachen Anweisungen „alle Bugs“ zutage“.

Anders gesagt, die KI ersetzt den Forscher nicht, sie gibt ihm zehn Arme. Das passt zu dem, was ich Anfang September erzählt habe, als OpenAI, Google und Anthropic am selben Tag ihre KI herausgebracht hatten, die hackt: Diese Werkzeuge wurden für die Verteidiger angekündigt, und diesmal waren es tatsächlich sie, die zuerst zugeschlagen haben. OpenAI behauptet, dass die Sicherheitslücken nach seinem Kenntnisstand von der KI gefunden wurden, bevor Angreifer sie fanden.

Trotzdem zwei Tage Panik

Der Plan war sauber: zwei Monate geheime Arbeit mit dem PHP-Team, Cloudflare, den Herausgebern von Linux-Systemen und den US-Behörden, dann eine Veröffentlichung zu einer festen Uhrzeit, am Mittwoch, dem 21. Oktober um 16 Uhr Brüsseler Zeit, damit alle gleichzeitig aktualisieren konnten. Nur dass vorher Details durchgesickert waren, in einer Diskussion auf Hacker News, dem großen Forum der Entwickler. Ergebnis, PHP zog seine Veröffentlichung vor, und das Hackerbüro öffnete früher als geplant.

Cloudflare, das Unternehmen, das einen riesigen Teil der Websites weltweit schützt und beschleunigt, aktivierte für alle seine Kunden, auch die kostenlosen, um 5 Uhr 02 morgens (Brüsseler Zeit) Filterregeln, neun Stunden vor der Veröffentlichung. Und seine Teams sahen live, wie die Angreifer ihre Anfragen veränderten, um durchzukommen. watchTowr, ein anderes Sicherheitsunternehmen, bestätigte laut The Next Web Angriffsversuche auf die beiden Sicherheitslücken. Währenddessen fror Laravel, eines der Lieblingswerkzeuge der PHP-Entwickler, die Veröffentlichungen seiner Kunden ein, solange alles mit der korrigierten Version neu aufgebaut wurde.

Und OpenAI kündigt am selben Tag in seinem Beitrag großzügig eine Milliarde Dollar subventionierten Zugang zu seinen Sicherheitstools für Organisationen an, die sich diese nicht leisten können. Das Unternehmen warnt auch, dass diese Art von Entdeckung „in den kommenden Monaten stark zunehmen“ wird. Wir sind gewarnt.

Betrifft das konkret deine Website?

Wenn du eine WordPress-Website, einen Shop oder ein Blog bei einem gewöhnlichen Hoster hast (OVH, o2switch, Hostinger, Infomaniak und die anderen), installiert fast immer dein Hoster PHP, und deshalb ist er auch für das Update zuständig. Aber begnüge dich nicht damit, das anzunehmen: Geh in deinen Kundenbereich, such nach der Zeile „PHP-Version“ und schau dir die Zahl an.

Fünf Minuten in deinem Kundenbereich, und du weißt, ob du ruhig schlafen kannst

Die korrigierten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Wenn du 8.1, 8.0 oder schlimmer eine alte 7.irgendwas siehst, wird es heikel: Das PHP-Projekt korrigiert diese Versionen nicht mehr. Einige Hoster und Linux-Herausgeber wenden die Korrektur trotzdem ihrerseits an, also stell ihnen die Frage schriftlich. Und wenn sie nichts Klareres antworten, nutz die Gelegenheit, deine Website auf eine aktuelle Version zu bringen: Dein WordPress hat das wahrscheinlich schon seit Monaten von dir verlangt.

Warum sich wegen einer kleinen Website abmühen, die nichts Wichtiges enthält? Weil ein Hacker, der die Kontrolle über deinen Server übernimmt, nicht unbedingt deine Daten will. Er will deine Maschine: um in deinem Namen Tausende Betrugsmails zu verschicken, eine gefälschte Bankseite zu hosten oder als Relais zu dienen, um jemand anderen anzugreifen. Und dein Domainname landet schließlich auf den schwarzen Listen.

Und wenn du keine Website hast? Dann hast du nichts zu tun. Als einfacher Besucher riskierst du nichts, wenn du eine Seite öffnest, die Lücke zielt auf die Server, nicht auf deinen Browser. Der einzige Effekt, den du vielleicht sehen wirst, ist eine Verwaltungswebsite, die diese Woche «wegen Wartungsarbeiten» nicht erreichbar ist. Jetzt weißt du, warum.

Nur so nebenbei, die Website, auf der du mich liest, läuft auf .NET, nicht auf PHP. Zum ersten Mal sind mir fünfundzwanzig Jahre .NET ein Regenschirm!

Wenn du Entwickler bist

Du kannst diesen Teil überspringen, wenn du keinen Server verwaltest. Die beiden Lücken tragen die offiziellen Nummern CVE-2026-109618 und CVE-2026-109619 (das Nummernschild der bekannten Lücken), und PHP gibt ihnen einen Schweregrad von 9,2 von 10. Die PHP Foundation stellt klar, dass alle Installationen betroffen sind, die Seiten ausliefern: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Der am stärksten gefährdete Fall ist mod_php, bei dem eine anonyme Anfrage das Problem auslösen kann, bevor dein Code überhaupt startet. Achtung vor einer klassischen Falle: Die PHP-Version, die du in deinem Terminal siehst, ist nicht immer die, die dein Webserver verwendet. Überprüfe beide, die zweite auf einer Diagnoseseite deines Hosters oder in deinem Administrationsbereich. Im Terminal sieht das so aus:

php -v
php -i | grep -i "upload_progress"

Wiz rät, auf drei Anzeichen eines Angriffs zu achten: Uploads in mehreren Teilen, gefolgt von Speicherfehlern oder Salven von 500-Fehlern, ungewöhnlich lange oder fehlerhaft formatierte PHPSESSID-Cookies und PHP-Prozesse, die ohne Grund neu starten. Die kursierenden Notfallmaßnahmen (session.upload_progress deaktivieren, post_max_size verringern, display_errors auf null setzen) verringern das Risiko, aber PHP sagt es ganz klar: Nur das Update behebt das Problem. Und sobald alles aktuell ist, schau nach, ob nicht schon jemand eingedrungen ist. Wie Madelein van der Hout, Analystin bei Forrester, in Erinnerung ruft: Ein Patch schließt die Tür, er bringt nicht denjenigen aus dem Haus, der schon darin ist.

Meine Meinung

Ich finde diese Geschichte ziemlich beruhigend, und das überrascht mich selbst. Eine seit Jahren im Motor von sieben von zehn Websites versteckte Lücke, von mit KI bewaffneten Verteidigern gefunden, innerhalb von zwei Monaten behoben, während alle an einem Tisch sitzen, und Websites, die sich vorsichtshalber abschalten, statt die Daumen zu drücken: Genau so sollte es laufen. Das Leck in letzter Minute zeigt nur, dass ein Geheimnis nie bis zum Ende geheim bleibt.

Was mir Sorgen macht, ist, was danach kommt. Die Hacker haben dieselben Modelle, sie lesen dieselben Patches, und ihre Bots schlafen nicht. Vor weniger als drei Wochen habe ich von einer Lücke erzählt, die innerhalb eines Tages ausgenutzt wurde. Die Frage ist also nicht mehr, ob es wieder passiert, sondern wie viele vergessene kleine WordPress-Websites mit ihrem PHP 7 von vor fünf Jahren bis Weihnachten als Kanonenfutter dienen werden. Los, überprüf deine Version, das dauert fünf Minuten!

Quellen

• Wiz Research, 21. Oktober 2026: PHP2Shell, die Chronologie, die vier Bugs und die betroffenen Anwendungen
• OpenAI, 21. Oktober 2026: Patch the Planet, die Koordination der Reaktion auf PHP-Sicherheitslücken
• The Next Web: PHP veröffentlicht Notfallpatches für zwei Sicherheitslücken, die zuerst von der KI entdeckt wurden
• CSO Online: zwei kritische PHP-Sicherheitslücken versetzen das Web in Alarmbereitschaft
• Tenable: häufig gestellte Fragen zu PHP2Shell

Artikel mit Hilfe von Claude Code geschrieben, von mir gelesen und korrigiert.