Erster KI-generierter Zero-Day in freier Wildbahn

Worüber die Security-Community seit Monaten spekuliert, hat Google jetzt erstmals dokumentiert: Kriminelle haben ein KI-Modell genutzt, um eine bisher unbekannte Schwachstelle zu finden und in einen funktionierenden Exploit umzuwandeln. Das geht aus einem Bericht der Threat Intelligence Group (GTIG) vom 11. Mai 2026 hervor.

Google konnte den geplanten Massenangriff verhindern. Trotzdem lohnt sich ein genauer Blick, weil der Fall zeigt, wie sich die Bedrohungslage gerade verändert.

Was passiert ist

Laut GTIG steckt eine Gruppe organisierter Cyberkrimineller dahinter. Ihr Ziel: ein weit verbreitetes Open-Source-Tool für die Systemadministration. Google nennt weder den Namen des Tools noch eine CVE-Nummer. Die Schwachstelle ist inzwischen gepatcht.

Die Lücke selbst steckte in der Zwei-Faktor-Authentifizierung: Ein Entwickler hatte eine Vertrauensausnahme fest im Code verankert, die den gesamten 2FA-Mechanismus aushebelte, sobald ein Angreifer gültige Zugangsdaten besaß. Kein Buffer Overflow, keine fehlerhafte Eingabevalidierung. Stattdessen ein semantischer Logikfehler: Der Code tat, was er sollte, aber was er sollte, war falsch.

Die Angreifer ließen ein KI-Modell den Quellcode analysieren und die Lücke finden. Anschließend generierte das Modell ein Python-Skript, das den 2FA-Bypass automatisiert. Der Plan: massenhafte Ausnutzung gegen möglichst viele Installationen gleichzeitig. GTIG konnte die Aktivität rechtzeitig erkennen und zusammen mit dem betroffenen Hersteller die Schwachstelle schließen, bevor die Kampagne anlaufen konnte.

Woran Google erkannte, dass KI im Spiel war

Das Python-Exploit-Skript trug unverkennbare Spuren eines Large Language Models. GTIG macht das an mehreren Stellen fest.

Zum einen war das Skript durchzogen von ausführlichen Docstrings, die den Code Schritt für Schritt erklären, wie in einem Tutorial. Zum anderen enthielt es einen CVSS-Score für die Schwachstelle, den kein reales CVE-System vergeben hatte. Das Modell hat ihn schlicht halluziniert. Dazu kam ein auffällig sauberer Pythonic-Stil mit ANSI-Farbklassen und detaillierten Hilfemenüs. So schreibt kein Angreifer, der schnell einen Exploit zusammenhackt. So schreibt ein Modell, das "guten Code" gelernt hat.

Welches KI-Modell genutzt wurde, sagt Google nicht. Nur so viel: Gemini war es nicht.

Warum KI genau diesen Fehler finden konnte

Kein Fuzzer hätte diese Schwachstelle gefunden. Kein statisches Analysetool. Es war kein klassischer Bug, sondern ein Widerspruch zwischen dem, was der Entwickler wollte, und dem, was der Code tatsächlich tut.

Laut GTIG sind Frontier-LLMs genau bei dieser Art von Fehler stark: Sie lesen die Absicht des Entwicklers mit und vergleichen sie mit dem tatsächlichen Verhalten. Fest kodierte Anomalien, die in einem Review als "sieht korrekt aus" durchgehen, fallen dem Modell auf. Traditionelle Scanner arbeiten regelbasiert und übersehen solche semantischen Widersprüche.

Das ist unangenehm für alle, die Open-Source-Abhängigkeiten in ihrer Infrastruktur haben (also praktisch alle). Die Angriffsfläche verschiebt sich weg von bekannten CVEs und fehlenden Patches hin zu Logikfehlern, die seit Jahren unentdeckt im Code liegen und jetzt systematisch auffindbar werden.

Das größere Bild: GTIG-Report zeigt industrielle Nutzung

Der Zero-Day-Exploit ist der prominenteste Fund im GTIG-Report, aber bei weitem nicht der einzige. Google beschreibt eine Entwicklung, bei der KI-Nutzung durch Angreifer vom Experiment zur Routine wird.

Ein Beispiel dafür ist PROMPTSPY, eine Android-Backdoor, die ein Gemini-Modell direkt integriert. Die Malware navigiert eigenständig durch die Android-Oberfläche, interpretiert den Systemzustand und kann biometrische Authentifizierungsgesten abfangen und nachspielen. Der Angreifer gibt keine einzelnen Befehle mehr. Das Modell entscheidet autonom.

Mindestens genauso beunruhigend: Supply-Chain-Angriffe treffen jetzt die KI-Infrastruktur selbst. Eine Gruppe namens TeamPCP hat das populäre LiteLLM-Projekt (ein API-Gateway für LLM-Anbieter) über manipulierte Pull Requests kompromittiert und AWS-Schlüssel sowie GitHub-Tokens aus Build-Umgebungen abgegriffen. Auch der Trivy-Vulnerability-Scanner und Checkmarx-Repositories waren betroffen.

Und dann ist da noch die Industrialisierung des Zugangs: Mehrere Gruppen betreiben Proxy-Infrastruktur, um gestohlene oder automatisch registrierte Premium-Accounts bei Claude, Gemini und OpenAI zu bündeln. Tools mit Namen wie "Claude-Relay-Service" und "CLIProxyAPI" fungieren als API-Gateways für den Zugriff im großen Stil.

Was Google auf der Verteidigungsseite einsetzt

Google setzt auf der Verteidigungsseite dieselben Mittel ein. Big Sleep, ein KI-Agent von DeepMind und Project Zero, sucht eigenständig nach Schwachstellen in Software. Laut GTIG hat Big Sleep bereits eine reale Schwachstelle gefunden, die Angreifer unmittelbar ausnutzen wollten, und Google konnte sie rechtzeitig schließen. CodeMender, ein experimenteller Gemini-Agent, soll gefundene Schwachstellen dann automatisch patchen.

Zusammen mit Anthropics Claude Mythos, das seit April bei ausgewählten Partnern im Einsatz ist, wächst auf der Verteidigungsseite ein neues Feld: KI-gestützte Schwachstellensuche, die schneller arbeitet als menschliche Researcher. Das Wettrüsten läuft.

Was das für euer Team heißt

Wer Open-Source-Komponenten mit Authentifizierungslogik einsetzt, sollte sich fragen, ob manuelle Code-Reviews allein noch ausreichen. Semantische Logikfehler, die für menschliche Reviewer korrekt aussehen, sind jetzt systematisch auffindbar. Tools wie Semgrep, CodeQL oder kommerzielle SAST-Lösungen integrieren zunehmend LLM-basierte Analyse. Es lohnt sich zu prüfen, ob das in den eigenen Workflow passt.

Die Kompromittierung von LiteLLM und Trivy zeigt außerdem: KI-Infrastruktur-Tools werden selbst zum Angriffsvektor. LLM-Gateways, MCP-Server und KI-Coding-Agenten in der Entwicklungsumgebung verdienen dieselbe Aufmerksamkeit wie Produktionsabhängigkeiten.

Und noch etwas Konkretes: Der dokumentierte Angriff umging 2FA nicht durch Social Engineering oder SIM-Swapping, sondern durch einen Logikfehler in der Implementierung. Wer selbst gehostete Admin-Tools mit eigener 2FA-Integration betreibt, hat jetzt einen guten Anlass, sich den Code nochmal anzuschauen.