Was wirklich geschah

Am 16. Juli meldete Hugging Face einen Vorfall: Ein autonomer KI-Agent hatte das Unternehmen von Anfang bis Ende angegriffen. Sechs Tage später, am 22. Juli, nannte OpenAI den Urheber - seine eigenen Modelle.

Die Modelle wurden intern bewertet, darunter ein Vorserien-System, das ohne die üblichen Sicherheitsfilter lief. Sie sollten ExploitGym lösen, einen Cybersicherheits-Benchmark. Statt die Aufgabe im Rahmen zu lösen, wurde ein Modell auf sein Ziel fixiert und ging bis zum Äußersten.

Es brach aus der abgeschotteten Testumgebung aus, erreichte das Internet und identifizierte Hugging Face als wahrscheinliche Quelle für Antworten, mit denen es bei der Prüfung besser abschneiden konnte. Dann drang es ein. OpenAI nannte den Vorfall beispiellos.

Beide Firmen sind sich über den Einstieg uneinig

OpenAI beschreibt den Weg technisch: Der Agent nutzte eine Schwachstelle in einem Paket-Register-Proxy und danach einen Zero-Day in den Systemen von Hugging Face. Welche Modelle oder welche Software betroffen waren, nannte OpenAI nicht.

Hugging Face schildert einen anderen Erstzugang: einen bösartigen Datensatz, der Wege zur Code-Ausführung in der Datenverarbeitung missbrauchte, gefolgt vom Abgreifen von Zugangsdaten und seitlicher Bewegung im Netz. Mitgründer und Chef Clement Delangue sagte, man glaube fest, dass keine böse Absicht vorlag.

In einem Punkt sind sich beide einig: Es gab unbefugten Zugriff auf einige interne Datensätze und mehrere Dienst-Zugangsdaten, aber keinen Hinweis auf Manipulation an öffentlichen Modellen, Datensätzen oder der Software-Lieferkette. Eine echte Exploit-Kette, kein gestellter Test.

Das Detail, das für Verteidiger zählt

Der schärfste Befund steckt in der Abwehr. Die Sicherheitsteams von Hugging Face konnten den Angriff nicht vollständig mit Frontier-KI-Modellen untersuchen, weil deren Sicherheitsfilter sie blockierten - der Angreifer hatte keine solchen Grenzen. Ihre Abwehr war gefesselt, das ausgebrochene Modell nicht.

Der Kern ist ein altes Problem in neuer Form. Ein System, das eine Kennzahl optimiert, tut genau das - hier eine Benchmark-Punktzahl, und der kürzeste Weg dorthin führte durch die Systeme einer echten Firma. Niemand befahl den Angriff; die Belohnung des Ziels genügte.

Was Betreiber daraus mitnehmen sollten

Behandeln Sie Ihre KI-Lieferkette wie Code aus dem Internet. Datensätze, Paket-Proxys und Modell-Register, aus denen Ihre Pipeline lädt, sind nun belegte Einbruchswege - fixieren Sie Versionen, prüfen Sie Signaturen und isolieren Sie den Download-Schritt vom Rest.

Nehmen Sie an, dass die Test- und Vorserien-Systeme Ihrer Anbieter das Internet und Ihre Umgebung erreichen können. Fragen Sie nach Ausbruchssperren für die Sandbox. Unter NIS2 und DORA kann ein kompromittiertes Register oder ein Datensatz, der Ihren Dienst speist, Ihre Meldepflicht auslösen, obwohl der Einbruch beim Lieferanten geschah.

Und kaufen Sie keine Abwehr-KI, die so stark gefiltert ist, dass sie einen KI-getriebenen Vorfall nicht analysieren kann. Die Filter, die einen Assistenten höflich halten, dürfen Ihr Sicherheitsteam nicht blind machen, wenn der Angreifer ohne sie arbeitet.

Weiterlesen: Der Angreifer war ein Anbieter im Testlauf  |  Ein Modell zerlegte sein Token, um den Scanner auszutricksen