Am 11. Mai 2026 hat Google Threat Intelligence Group (GTIG) einen Befund veroeffentlicht, den die Branche seit zwei Jahren befuerchtet und gleichzeitig nicht wahrhaben wollte: Es gibt jetzt einen dokumentierten Fall, in dem ein krimineller Akteur ein grosses Sprachmodell genutzt hat, um eine bislang unbekannte Schwachstelle in einer real eingesetzten Software zu finden und in einen funktionierenden Zero-Day-Exploit zu verwandeln. Ziel: ein Massenausbruchsszenario gegen eine populaere Open-Source-Plattform fuer Web-basierte Systemadministration. GTIG sagt mit hoher Konfidenz, dass die Schwachstellensuche, die Exploit-Konstruktion und die Hilfsskripte mit Hilfe eines KI-Modells entstanden sind – und nennt das eine Zaesur.

Die Kurzfassung fuer eilige Leser: Der Exploit war ein 2FA-Bypass. Wer gueltige Zugangsdaten hatte, konnte den zweiten Faktor in der Zielsoftware ueberspringen. Die Schwachstelle entstand, weil ein Entwickler eine fest verdrahtete Vertrauensausnahme in den Authentifizierungspfad eingebaut hatte. Die Annahme: An dieser Codestelle ist der Benutzer bereits authentifiziert. Die Realitaet: Die Annahme galt im Aufrufpfad nicht. Genau die Sorte semantischer Logikfehler, die ein Mensch in einem Code-Review uebersieht und ein Sprachmodell mit ausreichend Kontext sehr zuverlaessig findet.

Was genau ist passiert

GTIG fasst die Erkenntnisse in einem laengeren Bericht zusammen, den der Google-Cloud-Blog am 11. Mai 2026 veroeffentlicht hat. Der Befund stammt nicht aus einer Forschungssimulation, sondern aus realer Telemetrie. Ein nicht naeher benannter krimineller Akteur arbeitete mit mindestens einem grossen Sprachmodell zusammen, um eine 2FA-Umgehung in einem weit verbreiteten Open-Source-Administrationswerkzeug zu finden. Die Akteure planten eine massive Exploitation-Welle – also keinen gezielten Einzelangriff, sondern den koordinierten Zugriff auf moeglichst viele exponierte Installationen weltweit.

Google nennt den Namen des betroffenen Produkts bewusst nicht, koordinierte die Offenlegung mit dem Hersteller und veroeffentlichte den Bericht erst, nachdem ein Patch im Umlauf war. Das ist Lehrbuch-Disclosure – und das Wichtigste daran ist: Die Welle wurde vermutlich verhindert. John Hultquist, Chefanalyst bei GTIG, sagte sinngemaess: Wir haben den Angriff aufgehalten, bevor er Schwung aufnehmen konnte. Aber wir wissen auch, dass fuer jeden KI-Exploit, den wir nachweisen koennen, vermutlich viele unentdeckt bleiben.

Warum die Analysten sicher sind, dass eine KI mitgearbeitet hat

Die spannendste Stelle des GTIG-Berichts ist die Forensik der Code-Artefakte. GTIG nennt vier Indikatoren, die zusammen ein klares Bild ergeben:

1. Halluzinierter CVSS-Score. Das Exploit-Skript trug einen CVSS-Score, der nicht zur Schwachstelle passte und auch in keiner Datenbank existierte. Sprachmodelle erfinden solche Scores routinemaessig, weil sie wissen, dass professionelle Exploits CVSS-Bewertungen tragen, aber den exakten Wert nicht berechnen koennen.

2. Lehrbuchhafte Python-Struktur. Der Code war in einem Stil geschrieben, der nicht zu Untergrund-Exploits passt: saubere Funktionssignaturen, konsistente Einrueckung, idiomatische Verwendung von requests und argparse, defensive Pruefungen. Untergrund-Skripte sind in der Regel hektischer, mit Copy-Paste-Spuren und kommerziellen Dependencies.

3. Paedagogische Docstrings. Funktionen waren ausfuehrlich dokumentiert mit Beispielen und Hinweisen, was die Funktion macht und wie man sie aufruft. Eine Sorte Kommentar, die Entwickler nicht in produktive Angriffsskripte schreiben, weil sie keinen Mehrwert haben. Sprachmodelle schreiben sie, weil ihr Trainingsdatensatz zu grossen Teilen aus Lehrmaterialien besteht.

4. Detaillierte Hilfemenues. Das Skript hatte eine --help-Ausgabe, die ein Anfaenger durch jeden Schritt fuehrt. Ein Profi schreibt das nicht selbst. Ein LLM tut es reflexartig.

Google betont ausdruecklich, dass weder Gemini noch andere namentlich genannte Modelle als Quelle identifiziert wurden. Welcher Anbieter im Hintergrund stand, bleibt offen. Das ist relevant, weil sich der Befund nicht in einen Anbieterstreit aufloesen laesst. Die Faehigkeit, semantische Logikfehler in fremdem Code zu finden, ist in der aktuellen Modellgeneration generisch vorhanden.

Die technische Schwachstelle im Detail

Auch wenn GTIG das Produkt nicht nennt, beschreibt der Bericht die Klasse der Luecke praezise. Es handelt sich um einen Authentication-Bypass durch eine fest verdrahtete Vertrauensannahme. Der Aufrufpfad sah ungefaehr so aus: Eine interne Methode, die normalerweise nach erfolgreicher Erstauthentifizierung aufgerufen wird, hatte eine Vorbedingung, dass der Benutzer bereits durch den Erstauthentifizierungsschritt gegangen ist. Diese Vorbedingung war im Code als Kommentar dokumentiert, aber nicht als Code erzwungen.

Ein zweiter Code-Pfad – ein Webhook-Endpunkt mit anderer Berechtigungslogik – rief dieselbe interne Methode auf, ohne die Erstauthentifizierung garantieren zu koennen. Das Sprachmodell fand diese Diskrepanz, indem es die Aufrufgraphen verglich und die Vertrauensgrenze identifizierte, die einmal galt und einmal nicht. Der Exploit bestand dann nur noch aus einem geformten HTTP-Request gegen den Webhook-Endpunkt mit einem Token, das im Erstauthentifizierungsschritt nie ausgestellt worden waere.

Das Ergebnis: Ein Angreifer mit gueltigen Zugangsdaten zum ersten Faktor (etwa aus einem fruheren Credential-Leak oder aus einer Phishing-Kampagne) konnte den zweiten Faktor umgehen. In einer Welt, in der 86 Prozent aller Phishing-Mails laut BSI-Cybersicherheitsmonitor 2026 KI-generiert sind und in der Credential-Leaks im Wochentakt auf der dunklen Seite des Netzes auftauchen, ist das eine sehr ernste Eskalation.

Warum gerade ein 2FA-Bypass

Zwei-Faktor-Authentifizierung ist seit Jahren die Standardempfehlung, mit der Sicherheitsverantwortliche Phishing-Risiken adressieren. Wenn ein Angreifer das Passwort hat, soll der zweite Faktor verhindern, dass er einsteigt. Das Versprechen gilt allerdings nur, wenn das 2FA-Schema lueckenlos implementiert ist. Sobald ein einziger Aufrufpfad die 2FA-Pruefung umgeht, faellt die gesamte Schutzschicht weg.

Solche Pfade gibt es haeufiger, als die meisten IT-Verantwortlichen wahrhaben wollen: API-Endpunkte, die noch aus der Pre-2FA-Aera stammen, interne Verwaltungsoberflaechen, Webhook-Handler, alte SOAP-Schnittstellen, mobile App-Endpunkte mit eigenem Token-Schema. Jeder dieser Pfade ist ein potenzieller Bypass, wenn er die zentrale Auth-Pruefung nicht konsequent durchlaeuft. Genau diese Art von Inkonsistenz finden Sprachmodelle besser als Menschen, weil sie den gesamten Aufrufgraphen ohne Ermuedung lesen.

Der breitere GTIG-Befund: KI im gesamten Angriffslebenszyklus

Der Zero-Day ist nicht der einzige Befund des Berichts. GTIG dokumentiert auch, dass staatlich gesteuerte Akteure aus China, Nordkorea und Russland KI inzwischen ueber den gesamten Angriffslebenszyklus einsetzen: Reconnaissance, Phishing-Generierung, Opferprofilierung, Exploit-Entwicklung, Post-Exploitation-Automation. Konkrete Malware-Familien wie PROMPTSTEAL und PROMPTFLUX, die Google bereits Ende 2025 dokumentiert hat, fragen Sprachmodelle zur Laufzeit ab, um ihren eigenen Code dynamisch umzuschreiben.

Was wir am 11. Mai 2026 sehen, ist also kein Einzelfall, sondern ein Punkt auf einer Kurve. Die Branche hat seit Jahren diskutiert, ob KI die Angreiferseite mehr beguenstigt als die Verteidigerseite. Der GTIG-Bericht beantwortet die Frage zumindest fuer das aktuelle Jahr nicht zugunsten der Verteidiger.

Was Sie konkret tun sollten

Wir haben die wichtigsten Massnahmen in fuenf Handlungsfelder gegliedert. Die Liste richtet sich an IT-Verantwortliche im Mittelstand und priorisiert das, was in den naechsten 72 Stunden umsetzbar ist.

1. Inventarisieren Sie Ihre 2FA-Oberflaechen

Listen Sie jede Anwendung, jeden Webdienst und jede API auf, die heute Zwei-Faktor-Authentifizierung verlangt. Pruefen Sie dann fuer jede dieser Anwendungen, ob es Aufrufpfade gibt, die die 2FA-Pruefung umgehen koennten: Webhook-Endpunkte, Service-zu-Service-APIs, Mobile-Backends, Legacy-Endpunkte. Das ist nicht trivial, aber es ist die einzige Massnahme, die den GTIG-Vorfall direkt adressiert.

2. Pruefen Sie Ihre Open-Source-Administrationswerkzeuge

Wenn Sie Open-Source-Adminoberflaechen einsetzen – Portainer, Cockpit, Webmin, Nextcloud-Admin, Grafana-Adminbereiche, n8n, Apache Airflow, Mailcow, Proxmox, Zammad, Bookstack – pruefen Sie deren Patchstand und bringen Sie sie aus dem oeffentlichen Internet ins VPN oder hinter einen Zero-Trust-Proxy. Genau diese Klasse von Software war Ziel des GTIG-Vorfalls, und ihre Angriffsoberflaeche ist im Mittelstand massiv unterschaetzt.

3. Erhoehen Sie die Patch-Geschwindigkeit

Mandiants M-Trends 2026 nennt eine erschreckende Zahl: 28,3 Prozent aller CVEs werden innerhalb von 24 Stunden nach Veroeffentlichung ausgenutzt. Mit KI-gestuetzter Exploit-Entwicklung wird sich dieser Wert weiter verschlechtern. Ihre Patch-Pipeline muss in der Lage sein, kritische Sicherheitsupdates fuer exponierte Systeme innerhalb von 24 Stunden zu installieren – Werktagslogik reicht nicht mehr.

4. Setzen Sie auf Phishing-resistente Faktoren

Klassische OTP-basierte 2FA (per SMS oder Authenticator-App) ist gegen AiTM-Phishing schon laenger nicht mehr robust. Der GTIG-Vorfall zeigt, dass auch die Anwendungsseite Schwachstellen tragen kann. Die einzige Antwort, die beide Angriffsvektoren reduziert, sind FIDO2/WebAuthn-Passkeys. Wir haben die Argumente fuer diese Migration in unserer Uebersicht zur Informationssicherheit ausfuehrlich beschrieben.

5. Logging und Anomalieerkennung priorisieren

Wenn der Bypass selbst nicht zu verhindern ist, muss er wenigstens auffallen. Das heisst: Authentifizierungsereignisse zentral loggen, ungewoehnliche Aufrufpfade gegen Webhook-Endpunkte alarmieren, neue API-Tokens nach Geolocation und Tageszeit pruefen. Wenn Ihr SIEM diese Faelle heute nicht erkennt, bauen Sie die Regeln vor dem naechsten KI-Zero-Day, nicht danach.

Die unbequeme Botschaft fuer 2026

Wir haben in den vergangenen Monaten mehrfach ueber den Wettlauf zwischen Angreifern und Verteidigern geschrieben – etwa bei der Analyse zu Akira und der SonicWall-VPN-Welle oder bei den Ollama-Luecken im KI-Update-Service. Der GTIG-Vorfall ist anders gelagert. Er sagt nicht "ein bekannter Bug wurde schneller ausgenutzt". Er sagt: "Eine Maschine hat einen Bug gefunden, den niemand vor ihr gesehen hat, und ihn in einen Exploit verwandelt." Das verschiebt die Risikorechnung jeder Software, die im Internet exponiert ist, nach oben.

Fuer den Mittelstand bedeutet das konkret: Die These, dass man als mittlerer Maschinenbauer, Fachverlag, Logistiker oder Beratungsunternehmen nicht im Fokus von Spezialisten steht, gilt nicht mehr. Spezialisten brauchen keine menschlichen Stunden mehr fuer die Schwachstellensuche. Sie brauchen einen Zielperimeter, einen Modellzugriff und Geduld. Die Wahrscheinlichkeit, dass die naechste KI-Welle gerade Ihre Open-Source-Adminoberflaeche scannt, ist nicht null, sondern steigt taeglich.

Wenn Sie wissen wollen, welche Massnahmen Sie zuerst angehen sollten und wie sich der Reifegrad Ihres Identity- und Patch-Stacks im Vergleich zur aktuellen Bedrohungslage verhaelt, sprechen Sie uns an. Eine erste Einschaetzung dauert nicht lange und kann den Unterschied zwischen einem geordneten Patchfenster und einem ungeplanten Incident-Response ausmachen. Sie erreichen uns ueber das Kontaktformular oder unsere Leistungsuebersicht.

Was als naechstes zu erwarten ist

Drei Entwicklungen halten wir in den kommenden Wochen fuer wahrscheinlich. Erstens: weitere Veroeffentlichungen anderer Threat-Intelligence-Teams (Mandiant gehoert ohnehin zu Google, aber auch Microsoft, Palo Alto Unit 42 und CrowdStrike koennten nachziehen), die aehnliche Befunde dokumentieren. Zweitens: Diskussionen ueber zusaetzliche Schutzmechanismen in den grossen Frontier-Modellen, etwa restriktivere Antworten auf Code-Analyseanfragen, die in Richtung Schwachstellensuche tendieren. Drittens: ein neues Geschaeftsmodell fuer Bug-Bounty-Programme, in dem Verteidiger ihre eigenen Modelle gegen ihre eigene Codebasis laufen lassen, bevor Angreifer es tun.

Fuer Sie als Verantwortliche heisst das: Verstehen, dass die Tempo-Asymmetrie zwischen Angriff und Verteidigung in den naechsten Quartalen weiter waechst, und entsprechend investieren. Nicht in immer mehr Tools, sondern in saubere Architektur, konsequente Patch-Disziplin und Phishing-resistente Authentifizierung. Genau diese Hausaufgaben standen schon vor dem 11. Mai 2026 auf der Liste. Sie sind jetzt nur dringender.