Eine KI fand die Lücke, die zehn Jahre niemand sah

Der Code, in dem PHP2Shell steckte, lief seit 2012. Vierzehn Jahre lang haben ihn Entwickler gelesen, Sicherheitsforscher geprüft und automatische Werkzeuge durchsucht. Gefunden hat die Lücke am 19. August 2026 ein KI-System. Nicht als Zufallstreffer, sondern als Ergebnis einer gezielten Suche durch Wiz Research, die dafür Wiz Atlas, Gemini 4 Argon und GPT-5.6 Sol eingesetzt haben. Betroffen sind nach ihren Angaben 70 Prozent aller Websites weltweit.

Für Geschäftsführer ist das keine Fachmeldung aus der Forschung. Es ist ein Hinweis darauf, dass sich das Tempo ändert, in dem solche Nachrichten künftig kommen.

Was daran bemerkenswert ist

PHP ist die am besten untersuchte Programmiersprache des Webs. Der Quelltext ist offen, tausende Entwickler lesen ihn, es gibt Prämienprogramme für gefundene Fehler, und automatische Prüfwerkzeuge laufen seit Jahren darüber.

Die Lücke lag trotzdem da. Und zwar nicht als ein offensichtlicher Fehler, sondern als Verkettung: Vier einzelne Schwächen, von denen jede für sich harmlos wirkt, ergeben zusammen den Weg zur Codeausführung. Der Speicher wird beim Abbruch einer Anfrage nicht sauber aufgeräumt, ein Teil davon lässt sich auslesen, ein anderer Teil lässt sich gezielt wieder belegen, und eine Typverwechslung im Zwischenspeicher macht daraus den Zugriff.

Genau diese Art von Fehler ist für Menschen schwer zu finden. Man muss vier Stellen gleichzeitig im Kopf behalten, die im Quelltext weit auseinanderliegen und von verschiedenen Leuten über Jahre geschrieben wurden. Für ein System, das den gesamten Code gleichzeitig betrachten kann, ist das eine andere Aufgabe.

Was das praktisch bedeutet

Das Zeitfenster wird kürzer

Bisher galt eine Faustregel: Zwischen dem Bekanntwerden einer Lücke und den ersten automatisierten Angriffen liegen Tage bis Wochen. Bei PHP2Shell waren es Stunden – und das nicht, weil die Angreifer schneller geworden wären, sondern weil die Details vorzeitig öffentlich wurden und ein funktionierender Angriffsweg sofort kursierte.

Die Sicherheitsfirma Sansec rechnete damit, dass die Massenausnutzung innerhalb von fünfzehn Minuten nach Veröffentlichung des Patches beginnt. Das ist der neue Maßstab, an dem sich ein Patch-Verfahren messen lassen muss.

Es wird mehr solcher Meldungen geben

Wenn sich mit KI Fehler finden lassen, die vierzehn Jahre unentdeckt blieben, dann gibt es davon mehr – in PHP, in Bibliotheken, in Betriebssystemen. Die Frage ist nicht, ob die nächste Meldung kommt, sondern wie gut Ihr Haus beim nächsten Mal aufgestellt ist.

Beide Seiten haben dieselben Werkzeuge

Das ist der unbequeme Teil. Dieselben Fähigkeiten, die Wiz zur Entdeckung genutzt hat, stehen auch denen zur Verfügung, die Lücken ausnutzen wollen. Bei PHP2Shell hat die Forschungsseite gewonnen: Die Lücke wurde im August gefunden, verantwortungsvoll gemeldet und im Oktober mit Patch veröffentlicht. Dass die Details vorzeitig durchsickerten, hat diesen Vorsprung verkürzt, aber nicht aufgehoben.

Darauf verlassen sollte man sich nicht.

Was Sie daraus mitnehmen sollten

Der Patchstand ist wichtiger geworden als die Patch-Strategie. Ein Verfahren, das Sicherheitsupdates beim nächsten Wartungsfenster einspielt, war jahrelang vertretbar. Bei einem Zeitfenster von Stunden ist es das nicht mehr. Was das konkret heißt, steht in Wartungsfenster und Patch-Management.

Sie müssen wissen, was Sie betreiben. Die häufigste Antwort auf die Frage „läuft bei Ihnen PHP" lautet „keine Ahnung". Ein Verzeichnis der eingesetzten Software ist kein Bürokratiethema, sondern die Voraussetzung dafür, bei der nächsten Meldung in Minuten statt in Tagen zu wissen, ob man betroffen ist. Dazu: Angriffsfläche von außen prüfen.

Verlassen Sie sich nicht darauf, dass Angreifer die Lücke erst verstehen müssen. Das war früher der stille Puffer zwischen Veröffentlichung und Angriff. Er schrumpft.

Was das nicht heißt

Ein paar Einordnungen, damit aus der Meldung keine falsche Schlussfolgerung wird.

Es heißt nicht, dass PHP unsicher ist. Jede Sprache dieser Größe hat solche Fehler. Dass dieser gefunden und behoben wurde, spricht für das Verfahren, nicht dagegen.

Es heißt nicht, dass Open Source das Problem ist. Im Gegenteil – dass der Quelltext offen liegt, hat die Untersuchung überhaupt erst ermöglicht. In geschlossener Software gibt es dieselben Fehler, nur findet sie dort niemand von außen.

Und es heißt nicht, dass KI jetzt alle Lücken findet. Wiz hat gezielt gesucht, mit erheblichem Aufwand und von Fachleuten geführt. Ein Sprachmodell findet nicht von allein Sicherheitslücken, so wie ein Mikroskop nicht von allein Krankheiten findet.

Warum vierzehn Jahre niemand darüber stolperte

Die naheliegende Frage lautet: Wie kann ein solcher Fehler so lange unbemerkt bleiben, wenn tausende Menschen den Code lesen?

Die Antwort hat mit der Art des Fehlers zu tun. Niemand hatte hier etwas offensichtlich falsch gemacht. Jede der vier Stellen war für sich betrachtet in Ordnung – der Speicher wird aufgeräumt, der Fehlerfall wird behandelt, der Zwischenspeicher arbeitet wie vorgesehen. Erst das Zusammenspiel ergibt die Lücke, und zwar nur in einer bestimmten Reihenfolge und unter einer Bedingung, die im Alltag selten eintritt: wenn eine Anfrage mitten im Vorgang an der Speichergrenze abbricht.

Ein Mensch, der eine dieser vier Stellen prüft, sieht nichts Auffälliges. Um den Fehler zu finden, muss man alle vier gleichzeitig im Kopf haben – über Dateigrenzen hinweg, über Jahre gewachsen, von verschiedenen Entwicklern geschrieben. Das ist weniger eine Frage von Sorgfalt als von Arbeitsgedächtnis.

Auch automatische Prüfwerkzeuge finden so etwas schlecht. Sie suchen nach bekannten Mustern – einer Funktion, die als unsicher gilt, einer Eingabe, die ungeprüft weiterwandert. Eine Verkettung aus vier unauffälligen Zuständen entspricht keinem Muster, nach dem jemand suchen würde.

Genau an dieser Stelle liegt der Unterschied. Ein System, das den gesamten Quelltext gleichzeitig betrachtet und Zusammenhänge über Dateigrenzen hinweg verfolgt, arbeitet nicht sorgfältiger als ein Mensch – es arbeitet anders. Das heißt nicht, dass es besser ist. Es heißt, dass es eine andere Sorte Fehler findet.

Der Bezug zu Ihrem Haus

Wenn Sie selbst KI im Unternehmen einsetzen oder das planen, ist dieser Fall ein nützliches Beispiel – und zwar für beides. Er zeigt, wozu diese Systeme in der Hand von Fachleuten taugen, und er zeigt, dass das Ergebnis geprüft werden muss: Wiz hat die gefundenen Fehler nachgewiesen, nicht behauptet.

Dieselbe Regel gilt im Kleinen für jeden Einsatz im Betrieb. Wie man Ergebnisse systematisch gegenprüft, steht in KI-Halluzinationen im Betrieb richtig prüfen.

Checkliste: erste Schritte

Wie DAVINCI unterstützt

Wir richten Patch-Verfahren so ein, dass ein kritisches Update nicht auf das nächste Wartungsfenster wartet, und sagen Ihnen, welche Systeme in Ihrem Haus überhaupt betroffen sein können. Zum Einsatz von KI im Betrieb beraten wir unter Künstliche Intelligenz. Bei PHP2Shell hilft kurzfristig der kostenlose PHP-Sicherheitscheck, Kontakt über die Kontaktseite.

Verwandte Themen: Wer hier weiterdenkt, liest bei Künstliche Intelligenz, KI-Richtlinie und Prozessautomatisierung weiter.