Mitte Juli 2026 gab Hugging Face einen Einbruch in seine Produktionsinfrastruktur bekannt, der von Anfang bis Ende von einem autonomen KI-Agenten gesteuert und größtenteils mit Hilfe der eigenen KI aufgedeckt und rekonstruiert wurde. Fünf Tage später nannte OpenAI den Urheber: seine eigenen Modelle. GPT-5.6 Sol und ein leistungsfähigeres, noch nicht veröffentlichtes Modell, deren Cyber-Abwehrmechanismen absichtlich abgeschwächt worden waren, wurden gerade anhand eines internen Benchmarks namens „ExploitGym“ getestet, als sie ausbrachen und Hugging Face angriffen.
Ohne den Rahmen betrachtet, bestand der Mechanismus aus einer Abfolge bekannter Grundelemente, die sich mühelos abliefen:
- Aus Sicht von OpenAI: Die Modelle nutzten eine zero-day Proxy der Paketregistrierung der Testumgebung aus, erweiterten ihre Berechtigungen und bewegten sich lateral zu einem Knoten mit Internetzugang. Anschließend nutzten sie gestohlene Anmeldedaten und weitere Exploits, um auf den Produktionsservern von Hugging Face Code aus der Ferne auszuführen und so den Antwortschlüssel für ExploitGym zu erbeuten.
- Aus Sicht von Hugging Face: Der Einstiegspunkt war die Datenverarbeitungspipeline, bei der die Ausführung nicht vertrauenswürdiger Benutzerinhalte eine Kernfunktion und kein Ausnahmefall ist. Ein bösartiger Datensatz nutzte zwei Codeausführungspfade aus (einen Loader für Remote-Code-Datensätze und eine Template-Injektion in einer Datensatzkonfiguration), um Code auf einem Worker auszuführen. Von dort aus erlangte der Agent Zugriff auf Knotenebene, sammelte cloud Cluster-Anmeldedaten und bewegte sich über ein Wochenende hinweg lateral über mehrere interne Cluster hinweg.
Es wurden keine öffentlichen Modelle, Datensätze oder Spaces manipuliert, die Lieferkette wurde als sicher bestätigt, und der Vorfall wurde den Strafverfolgungsbehörden gemeldet. Es erfolgte ein Zugriff auf interne Datensätze und Zugangsdaten für Dienste; Hugging Face meldete jedoch keine bestätigte Offenlegung von Kunden- oder Partnerdaten.
Und das war kein Einzelfall. In derselben Woche berichtete das britische AI Security Institute (AISI) über dasselbe Verhalten bei seinen eigenen Tests. Bei einer falsch konfigurierten und unlösbaren Cyber-Bewertung schrieb ein Modell Code und führte diesen auf einem externen Internetdienst aus, um zu versuchen, die Bewertungsinfrastruktur des AISI zu erreichen, was einen Sicherheitsalarm auslöste. Es kam zu keinem Datenleck und es entstand kein Schaden, da die Infrastruktur standhielt. Das ist der einzige Unterschied zu Hugging Face. Das AISI stellte außerdem fest, dass jedes von ihm getestete Modell versuchte, eine solche Abkürzung zu nehmen, was darauf hindeutet, dass es sich um ein Problem beim Training und bei der Ausrichtung handelt und nicht um ein einzelnes fehlerhaftes Modell.
Die Berichterstattung verfolgte die Flucht. Was zählt, ist der Fang.
Die meisten Berichte gingen von der Flucht aus: Eine KI, die ausbricht und ein anderes Unternehmen hackt. Ein US-Kongressabgeordneter bezeichnete dies als alarmierend und drängte auf obligatorische unabhängige Tests. Schärfere Stimmen wiesen darauf hin, dass vergleichbare Angriffe bereits mit Werkzeugen möglich sind, die weit außerhalb der Spitzenforschungslabore verfügbar sind, und dass die stichhaltigste Kritik sich auf OpenAI’s eigene Sicherheitsvorkehrungen richtete: Eine offensive Bewertung ohne Sicherheitsvorkehrungen in einer Umgebung durchzuführen, aus der das Modell entkommen könnte, ist eher ein Verfahrensfehler als eine Frage der Leistungsfähigkeit.
Eine Tatsache spricht jedoch gegen die Panikmache und sollte festgehalten werden: Die Erkennung hat funktioniert. Beide Teams haben die Aktivität unabhängig voneinander entdeckt, noch bevor die Unternehmen miteinander in Kontakt getreten waren. Der Angriff selbst ist nicht das Neue daran. Neu ist vielmehr, welche Auswirkungen der Vorfall auf die Tools hatte, auf denen die Reaktion basierte.
Problem 1: Der Haken lag in der Korrelation, nicht in den Anomalien
Kaum jemand hat darüber geschrieben, wie Hugging Face das entdeckt hat, was seltsam ist, da dies doch der Teil des Vorfalls ist, der am ehesten auf andere Fälle übertragbar ist.
Der Kompromiss kam durch KI-gestützte Erkennung ans Licht – eine Anomalie-Pipeline, die eine LLM-basierte Triage anhand von Telemetriedaten nutzt. Doch die Anomalien allein waren nur Rauschen. Entschieden war die Korrelation dieser Anomalien zu einem einzigen Signal – der Unterschied zwischen dem bloßen Markieren von Ungewöhnlichem und dem Erkennen eines Angriffs. Um die Vorgehensweise des Angreifers zu rekonstruieren, ließ das Team LLM-gesteuerte Analyse-Agenten das gesamte Aktionsprotokoll mit 17.000 Ereignissen durchlaufen, um die Zeitachse zu rekonstruieren, Indikatoren für eine Kompromittierung zu extrahieren und echte Auswirkungen von Ablenkungsmanövern zu unterscheiden.
Ein Wochenende voller Angriffe, eine Stunde für die Reaktion. Nach Angaben von Hugging Face selbst erstreckte sich die Kampagne über ein einziges Wochenende, umfasste Zehntausende automatisierter Aktionen, und die KI-gestützte Rekonstruktion dauerte etwa eine Stunde – eine Arbeit, die normalerweise Tage in Anspruch nehmen würde. Das funktionierte, weil den Agenten ein vollständiges, korreliertes Aktionsprotokoll zur Verfügung stand, auf dessen Grundlage sie Schlussfolgerungen ziehen konnten. Eine agentenbasierte Verteidigung ist immer nur so gut wie das ihr zugrunde liegende Signal: Erhält sie fragmentierte, eindimensionale Daten, übernimmt sie auch deren blinden Fleck.
Die clusterübergreifende Bewegung stellt ein Problem dar, das auf den ersten Blick nicht erkennbar ist (Lücke 3 in „Mind Your Attack Gaps“): vom Worker über den Knoten bis hin zu cloud und mehreren Clustern, ohne dass eine einzelne Ebene den Gesamtüberblick bietet. Der Einstiegspunkt ist jedoch konkret und nachweisbar: Jeder, der nicht vertrauenswürdige Datensätze einliest, sollte diese beiden Code-Ausführungspfade jetzt überprüfen – den Datensatz-Loader mit Remote-Code-Ausführung und die Template-Einfügung in einer Datensatzkonfiguration.
Problem 2: Die Leitplanken haben die Verteidiger ausgesperrt, nicht den Angreifer
Als Hugging Face mit der Protokollanalyse begann, griff das Team zunächst auf hochmoderne Modelle zurück, die hinter kommerziellen APIs standen. Das funktionierte nicht. Eine forensische Rekonstruktion erfordert die Übermittlung echter Angriffsbefehle, Exploit-Payloads und C2-Artefakte, und die Sicherheitsvorkehrungen der Anbieter, die nicht in der Lage waren, einen Incident-Responder von einem Angreifer zu unterscheiden, blockierten die Anfragen. Stattdessen führten sie die Analyse mit GLM 5.2, einem Modell mit offenen Gewichten, auf ihrer eigenen Infrastruktur durch. Daraus ergab sich ein weiterer Vorteil: Es verließen keine Angreiferdaten oder Anmeldedaten ihre Umgebung.
Man muss sich mit dieser Asymmetrie abfinden. Der Angreifer handelte völlig außerhalb jeglicher Nutzungsrichtlinien. Die von den Verteidigern bevorzugten Tools waren der Aufgabe nicht gewachsen. Die Abhilfemaßnahme verdeutlicht dies noch: OpenAI hat Hugging Face in sein „Trusted-Access“-Programm aufgenommen, das für legitime Sicherheitsarbeiten den Zugriff auf Modelle mit reduzierten Sicherheitsfiltern gewährt – genau jene Konfiguration mit reduzierter Ablehnungsrate, die den Vorfall ausgelöst hatte.
Diese Lektion sollte man beherzigen, bevor man sie braucht: Halten Sie ein leistungsfähiges Modell bereit, das Sie auf Ihrer eigenen Infrastruktur ausführen können – geprüft und einsatzbereit, noch bevor ein Vorfall eintritt –, um sowohl eine Sperrung durch Sicherheitsvorkehrungen zu vermeiden als auch die Daten der Angreifer im eigenen Haus zu behalten. Dies ist kein Argument gegen die Sicherheit von gehosteten Modellen. Es ist vielmehr ein Plädoyer dafür, Ihre DFIR-Tools unter Berücksichtigung der Möglichkeit zu planen, dass Ihr primäres Modell im Ernstfall versagt.
Problem 3: Es gibt keinen namentlich zu benennenden Angreifer
Ich habe einen Großteil des letzten Jahres damit verbracht, einen bestimmten Standpunkt zum Thema Cyberkriminalität zu vertreten: Man sollte das Verhalten im Blick behalten, nicht die Marke – denn während sich die Namen der Gruppen alle 18 Monate ändern, bleiben die Betreiber und die Vorgehensweise dieselben. Dieser Vorfall untermauert dieses Argument, und ich möchte ehrlich darlegen, inwiefern.
Aus den Angaben von Hugging Face ging nicht hervor, welches Modell die Agenten antrieb, oder ob es sich um ein gehostetes oder ein Open-Weight-Modell handelte. Der Kreis schloss sich nur, weil OpenAI sich zu Wort meldete. Nimmt man diese freiwillige Offenlegung weg, sind die üblichen Hinweise auf die Herkunft spärlich: keine Persona, kein Operator-Pool, der bewährte Vorgehensweisen wiederverwendet, und eine Kommando- und Kontrollstruktur, die bewusst über öffentliche Dienste hinweg migriert wurde.
Das Tracking des Verhaltens funktioniert nach wie vor auf technischer Ebene. Die Wiederverwendung von Anmeldedaten, die den Vorgang antreibt, ist ein Problem der erfolgreichen Authentifizierung (Lücke 2): gültige Anmeldedaten, die gesammelt und wiederverwendet werden, Protokolle, die den Erfolg dokumentieren, und die Möglichkeit, festzustellen, ob ein Mensch oder ein Modell dahintersteckt. Was jedoch an Bedeutung verliert, ist die darüberliegende Ebene: die Zuordnung auf Akteursebene, auf die sich CTI stützt, um zu sagen, wer verantwortlich ist, und um vorherzusagen, was als Nächstes passieren wird. Wenn es sich bei dem Akteur um ein Modell handelt, das ein eng gefasstes Ziel verfolgt, lässt sich das „Wer“ möglicherweise auf einen Benchmark-Lauf zurückführen.
Der Grundsatz „Verfolge das Verhalten, nicht die Marke“ gilt nach wie vor. Möglicherweise steckt hinter dem Verhalten einfach keine Marke, die man ausfindig machen könnte.
Was Sie ändern sollten, bevor es Sie trifft
All dies lässt sich nicht durch malware bessere malware lösen, da gar keine malware vorhanden war. Drei Maßnahmen sind entscheidend:
- Behandeln Sie die Daten und die Modelloberfläche als primäre Angriffsfläche. Bei KI-Plattformen sind nicht vertrauenswürdige Eingaben das Haupteingangsportal und kein Randfall.
- Setzen Sie KI bei der Rekonstruktion ein, damit die Reaktion mit der Geschwindigkeit des Angriffs erfolgt; dies funktioniert jedoch nur, wenn das zugrunde liegende Signal über alle Ebenen hinweg korreliert ist.
- Prüfen Sie ein selbst gehostetes Analysemodell vor einem Vorfall und nicht erst währenddessen, damit Ihre Einsatzkräfte niemals durch Sicherheitsvorkehrungen daran gehindert werden, zu reagieren.
In Lücke 3 spielte sich die eigentliche Bewegung dieser Intrusion ab, und es ist das Kapitel „Mind Your Attack Gaps“ , das ich als Erstes noch einmal lesen würde.