Am 21. Oktober 2026 nahm das Bundesministerium für Digitales und Staatsmodernisierung vorsorglich einen Teil seiner Websites vom Netz. Frankreichs Innenministerium deaktivierte die Websites lokaler Verwaltungsstellen. Behörden in Belgien, den Niederlanden, Finnland und Tschechien taten dasselbe. Auch der US-Geheimdienst NSA warnte; laut Al Jazeera riet er, Websites vom Netz zu nehmen, wenn sie sich nicht sofort aktualisieren lassen.
Der Grund waren zwei Fehler in PHP, der Programmiersprache, auf der die meisten Websites der Welt laufen. Laut den Forschern steckte der verwundbare Code seit mehr als zehn Jahren in PHP. Forscher, die mit künstlicher Intelligenz arbeiteten, zeigten, dass sich damit ein Server übernehmen lässt – wobei, wie die PHP Foundation später erklärte, eines der Probleme schon 2024 aufgefallen war.
Diese Geschichte handelt nicht nur von einem Notfall-Update. Sie zeigt, wie sich die Suche nach Schwachstellen in Software verändert – und warum das Verteidiger und Angreifer gleichermaßen betrifft.
Was PHP ist und warum es fast alle betrifft
PHP ist eine Sprache für die Serverseite von Websites: für das, was „hinter den Kulissen“ passiert, wenn man eine Seite öffnet, ein Passwort eingibt oder ein Formular abschickt. Verbreitete Content-Management-Systeme wie WordPress, Drupal und Joomla bauen darauf auf.
Laut W3Techs nutzen mit Stand 22. Oktober 2026 rund 69 % der Websites, deren serverseitige Sprache sich bestimmen lässt, PHP. Daher stammt die Zahl „70 % des Internets“ aus den Schlagzeilen. Sie ist ungefähr: Gezählt werden Websites, nicht Datenverkehr oder Daten, und nicht alle diese Websites waren gleich stark gefährdet.
Wer eine Website besucht, sieht PHP nie. Wird eine Seite, die man nutzt, aber gehackt, kann es auch einen selbst treffen: abgeflossene Daten, eine manipulierte Seite, ein schädlicher Link.
Was genau kaputt war
Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619; die Forscher nannten sie PHP2Shell. Beide wurden auf der Skala CVSS 4.0 mit 9,2 von 10 Punkten als kritisch eingestuft.
Vereinfacht liegt das Problem an zwei Stellen, an denen PHP eine Anfrage des Browsers verarbeitet:
- Geht während der Verarbeitung einer Anfrage der Speicher aus, hinterlässt PHP „Trümmer“, über die später die Aufräumroutine stolpert.
- Ein PHP-Arbeitsprozess kann Reste des Zustands einer vorherigen Anfrage weiterverwenden.
Man stelle sich einen Kellner vor, der den Tisch nach dem letzten Gast manchmal nicht abräumt – der nächste kann nutzen, was liegen geblieben ist. Jedes Versäumnis für sich ist harmlos. Die Forscher zeigten aber, wie man sie verkettet: dem Server eine speziell präparierte Anfrage schicken und ihn eigene Befehle ausführen lassen.
Besonders gefährlich machen das zwei Dinge. Erstens braucht es kein Passwort: PHP verarbeitet die Anfrage, bevor die Schutzmechanismen der Website überhaupt greifen. Zweitens ist laut Wiz fast jede PHP-Version von mindestens einer der Lücken betroffen, bis zurück zu 5.4 aus dem Jahr 2012. Versionen bis einschließlich 8.1 werden offiziell nicht mehr gepflegt: Für sie hat das PHP-Team nur minimale Quellcode-Patches veröffentlicht, einige Linux-Distributionen liefern eigene Korrekturen.
Wer sie gefunden hat und wie
Laut den Forschern der Sicherheitsfirma Wiz lief es so ab:
- 19. August: Die erste Lücke wird gefunden.
- 20.–21. August: Bestätigt, dass sich damit Websites mit Drupal und WordPress übernehmen lassen.
- 24. August: Meldung an das Sicherheitsteam von PHP.
- 21. September: PHP bestätigt das Problem und beginnt mit der Korrektur.
- 21. Oktober: Korrigierte Versionen erscheinen, Details werden veröffentlicht.
Doch Wiz war nicht als Erste dran. Die Firma Calif, die mit OpenAI zusammenarbeitete, gibt an, eine der Lücken schon früher mit GPT-5.6 Sol gefunden und am 11. August gemeldet zu haben. Wiz sagt, es habe die Lücken unabhängig davon entdeckt.
Ein Teil der Geschichte ist älter. Laut der PHP Foundation, zitiert von The Record, reicht die Geschichte von CVE-2026-109618 bis 2024 zurück, als PHP zum ersten Mal seit Jahren extern auf Sicherheit geprüft wurde: Damals war kein Weg bekannt, das Problem auszunutzen, und es geschah nichts. Die Entwickler waren sich zudem uneinig, wie es sich beheben lässt, ohne die Kompatibilität zu brechen, und die Arbeit geriet ins Stocken. Erst die Meldungen im August machten das volle Ausmaß deutlich; ab dem 11. August hatte die Korrektur für das Sicherheitsteam der Foundation höchste Priorität. Die Foundation gibt außerdem an, dass OpenAI, Wiz und Trail of Bits dieselben Lücken bei Prüfungen von PHP unabhängig voneinander fanden.
Wiz gibt an, durchgehend sein eigenes Werkzeug Wiz Atlas sowie die Sprachmodelle Gemini 4 Argon von Google und GPT-5.6 Sol von OpenAI eingesetzt zu haben. Laut den Forschern halfen die Modelle, die Lücken zu finden, den Exploit – also ein Programm, das eine Schwachstelle ausnutzt – zu schreiben und an verschiedene PHP-Versionen anzupassen sowie die Korrekturen zu prüfen. Ein einzelner Fachmann habe in einer Woche geschafft, wofür früher ein Spitzenteam Monate gebraucht hätte.
Hier lohnt die Unterscheidung. Dass KI geholfen hat, eine ausnutzbare Kette zu finden und den Exploit zu bauen, ist belegt: Alle Beteiligten sagen es, und die Schwachstelle ist real. „KI hat die Lücke gefunden“ ist eine Vereinfachung: Zumindest ein Teil der Schwachstelle war schon vorher aufgefallen; neu war der Nachweis, dass sie sich ausnutzen lässt – und das Tempo. Wie viel die Modelle und wie viel die Menschen beigetragen haben und wie stark sich die Arbeit beschleunigt hat, ist dagegen eine Einschätzung der Unternehmen selbst.
Wiz gehört zu Google – beide Firmen, deren Modelle zum Einsatz kamen, haben also ein Interesse an einer großen Geschichte. Eine unabhängige Analyse der Arbeitsteilung gibt es noch nicht.
Warum Behörden Websites abschalteten
Normalerweise werden kritische Lücken koordiniert offengelegt: zuerst die Korrektur, dann die Details. Diesmal ging der Plan schief. Laut SecurityWeek gelangten Details schon vor der geplanten Veröffentlichung der Patches ins Netz.
Am 20. Oktober kündigte PHP die Korrektur für den nächsten Tag an und rief Administratoren auf, sich vorzubereiten. Sicherheitsexperten rechneten mit massenhaften Angriffsversuchen wenige Minuten nach der Veröffentlichung. Später meldeten Firmen Ausnutzungsversuche, auch schon vor Erscheinen der Patches.
Cloudflare zählte binnen 45 Minuten nach der Offenlegung Zehntausende Versuche, am Morgen des 22. Oktober bereits Millionen. Einige Angreifer versuchten erfolglos, über die Lücken Potassium zu verbreiten, eine Variante der Botnetz-Schadsoftware Mirai.
Für die Administration einer Behörden-Website ist die Abwägung einfach: Lässt sich der Server nicht sofort aktualisieren, sind ein paar Stunden offline sicherer als das Risiko eines Einbruchs. Daher die Schlagzeilen über „dunkle“ Websites.
Auch Großbritannien war betroffen. Am 22. Oktober teilte eine Ministerin dem Oberhaus mit, dass 32 digitale Dienste der Regierung nicht verfügbar seien und 4 weitere nur eingeschränkt – vor allem aus Vorsicht. Das National Cyber Security Centre (NCSC) verschickte Warnungen an mehr als 50.000 britische Organisationen.
Mit Stand 23. Oktober melden Sicherheitsfirmen keinen bestätigten erfolgreichen Einbruch. Doch es ist früh: Die tatsächlichen Folgen werden meist erst Wochen später sichtbar.
Nicht das erste Mal, dass KI Fehler jagt
Im November 2024 meldete Googles Team Project Zero, sein KI-Agent Big Sleep habe eine bis dahin unbekannte Schwachstelle in SQLite gefunden, einer weit verbreiteten Datenbank. Der Fehler wurde noch am selben Tag behoben, bevor er in eine offizielle Version gelangte. Die Autoren schrieben damals vorsichtig, sie „glaubten“, dies sei das erste öffentliche Beispiel dieser Art.
In zwei Jahren hat sich die Größenordnung verändert. Damals: ein Fehler, geschlossen, bevor er Schaden anrichten konnte. Heute: eine Kette von Lücken im Fundament der meisten Websites, samt funktionierendem Angriff.
Auf der Reifeskala ist das keine Labordemonstration mehr: KI zur Suche nach Schwachstellen existiert und funktioniert heute. Offen ist, wie verbreitet sie wird und wer sie zuerst nutzt.
Ein Werkzeug für beide Seiten
Was folgt, ist Deutung, keine Tatsache.
Dieselbe Fähigkeit, die Wiz und Calif geholfen hat, steht auch denen offen, die Lücken für Angriffe suchen. Die Wiz-Forscher sagen es offen: Komplexität sei womöglich „keine nennenswerte Hürde mehr“. Viele gefährliche Fehler blieben bisher einfach deshalb unentdeckt, weil sie sehr schwer zu finden und auszunutzen waren. Senkt KI diese Hürde, könnte alter Code überall im Netz unsicherer sein als gedacht.
Doch die Seiten sind nicht gleich stark. Ein Angreifer muss nur einen einzigen ungepatchten Server finden. Verteidiger müssen alle aktualisieren. Der Engpass verschiebt sich daher vom Finden der Fehler zum Beheben: Jemand muss den Patch schreiben, testen und auf Millionen Servern installieren – manche davon mit Versionen, die nicht mehr gepflegt werden.
Es gibt auch eine menschliche Seite. Viele Grundtechnologien des Internets wie PHP werden von vergleichsweise kleinen Teams gepflegt. Findet KI immer mehr schwere Fehler, wächst die Last auf diesen Menschen.
Was wir noch nicht wissen
- Wie viele Systeme noch ungepatcht sind – und wie viele tatsächlich kompromittiert wurden. Mit Stand 23. Oktober schätzt Censys, dass mehr als 34 Millionen PHP-Dienste (Webdienste, nicht physische Server) weiterhin verwundbar sind; bestätigte massenhafte Einbrüche gibt es weiterhin nicht.
- Ob andere die Lücken früher gefunden haben. Der verwundbare Code existierte über zehn Jahre, und eines der Probleme fiel schon 2024 auf. Ob jemand sie heimlich nutzte, ist unbekannt. Amazon meldet, dass sein Honeypot-Netz schon am 17. Oktober, vier Tage vor der Offenlegung, einen Angriffsversuch registrierte; wie der Angreifer an die Details kam, ist unklar.
- Welcher Anteil der Arbeit auf die KI entfällt. Dazu äußern sich nur die Beteiligten.
- Wie viele ähnliche Fehler noch warten. Wenn KI so etwas in PHP fand, liegt die Vermutung nahe, dass es ähnliche Lücken in anderen alten Technologien gibt. Das ist aber eine Annahme, keine gesicherte Tatsache.
Drei plausible Szenarien
Die Verteidiger liegen vorn. Firmen und Open-Source-Entwickler prüfen alten Code in großem Maßstab mit KI und beheben Fehler, bevor Angreifer sie finden. Bedingung: Zugang zu solchen Werkzeugen und Menschen, die Korrekturen rechtzeitig ausliefern können.
Ein Wettlauf auf Augenhöhe. Notfall-Patches wie PHP2Shell werden Alltag, und die Zeit zwischen Offenlegung und ersten Angriffen schrumpft auf Minuten.
Der Engpass ist das Aktualisieren. Fehler werden schnell gefunden, doch alte, ungepatchte Server bleiben die größte Schwäche – und schnelles Aktualisieren wird zur wichtigsten Fähigkeit.
Diese Szenarien schließen sich nicht aus. Am wahrscheinlichsten verlaufen verschiedene Teile des Internets unterschiedlich.
Was das für Sie bedeutet
Wenn Sie eine Website betreiben – etwa mit WordPress –, fragen Sie Ihren Hosting-Anbieter, ob PHP aktualisiert wurde. Die korrigierten Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder neuer. Läuft Ihre Seite auf PHP 8.1 oder älter, gibt es keine offizielle Version mit der Korrektur – nur Patches für alle, die PHP selbst kompilieren, oder Korrekturen einiger Linux-Distributionen; dann lohnt es sich, den Umstieg auf eine gepflegte Version zu planen. Offizielle Warnungen veröffentlichen in Deutschland das BSI, in Österreich CERT.at und in der Schweiz das Bundesamt für Cybersicherheit (BACS).
Wenn Sie das Internet einfach nutzen, müssen Sie nichts Besonderes tun. Es ist aber ein guter Anlass, automatische Updates auf Handy und Computer einzuschalten und bei E-Mails wie „Aktualisieren Sie dringend Ihre Website“ misstrauisch zu sein – Betrüger lieben große Nachrichten.
Die wichtigste Lehre ist einfach: In der IT-Sicherheit gewinnt nicht, wer alle Fehler kennt, sondern wer sie schnell behebt.
Fragen zur Diskussion
- Ist es richtig, Behörden-Websites aus Sicherheitsgründen für ein paar Stunden abzuschalten, wenn Menschen in dieser Zeit keine Dienste nutzen können?
- Wer sollte für die Sicherheit von Technologien verantwortlich sein, auf die das ganze Internet angewiesen ist, die aber von vergleichsweise kleinen Teams gepflegt werden?
- Verändert die Rolle der KI Ihren Blick auf diese Geschichte: eher eine gute Nachricht für Verteidiger oder ein Warnsignal?
Log in or Sign up to join the discussion.