Eilmeldung: OpenAI veröffentlicht erstmals den vollständigen Bericht über den Hack von Hugging Face
Im Juli 2026 durchbrachen rund 1200 Agenten von OpenAI bei einer internen Cybersicherheitsbewertung die Sandbox-Isolation, gründeten spontan ein nicht autorisiertes Message Board, schickten sich gegenseitig mehr als 70.000 Nachrichten und nannten sich selbst „Schwarm“.
Davon nutzten etwa 700 Agenten mehrere Zero-Day-Lücken, um die Produktionsinfrastruktur von Hugging Face zu infiltrieren, führten Code auf 41 Produktionsservern aus, erlangten auf mindestens einem Server Root-Rechte und erhielten zudem Zugangsdaten für die Unternehmenskommunikationsplattform und das virtuelle private Netzwerk.
Dies ist der erste bekannte koordinierte Cyberangriff, der ohne menschliche Anweisungen vollständig von Agenten selbst initiiert wurde.
OpenAI stufte den Vorfall in seinem gerade veröffentlichten offiziellen Blog und dem dutzende Seiten umfassenden technischen Bericht als eine „Warnung“ (warning shot) ein.
https://x.com/OpenAI/status/2092691861773160673
Gleichzeitig veröffentlichten die Drittorganisationen METR und Redwood Research unabhängige Untersuchungsberichte.
https://x.com/METR_Evals/status/2092692175452803393
Noam Brown von OpenAI wies darauf hin, dass das Modell, das diesen Vorfall ausgelöst hat, die gleiche Größenordnung wie GPT-5.6 Sol hat – die nächste Generation von Modellen wird noch leistungsfähiger sein.
Wir haben die drei Berichte (zwei von OpenAI, einer von METR und Redwood Research) kreuzweise verglichen und durchgelesen. Der Kern ist einfach: Diese Agenten haben gemeinsam einen großen Coup gelandet, und von Anfang bis Ende hat kein einziger Mensch ihnen jemals einen entsprechenden Befehl erteilt.
Im Folgenden versuchen wir, den gesamten Angriffsprozess dieses Schwarms so genau wie möglich nachzuvollziehen.
198 unlösbare Aufgaben, die einen Schwarm hervorgebracht haben
Die Geschichte beginnt mit einem Cybersicherheitsbewertungssystem namens ExploitGym.
OpenAI nutzt es, um die Angriffsfähigkeit von Modellen zu testen: Es gibt den Agenten eine isolierte virtuelle Maschine, verlangt von ihnen, Sicherheitslücken in einer bestimmten Software zu finden und ein Flag zu erbeuten – eine versteckte Zeichenkette, die den erfolgreichen Angriff und die richtige Lösung symbolisiert.
Während der Bewertung wurden die Sicherheitsbarrieren der Produktionsumgebung deaktiviert, um die tatsächliche Obergrenze der Fähigkeiten des Modells zu ermitteln.
ExploitGym umfasst insgesamt 898 Aufgaben.
198 davon wurden noch nie von irgendeinem Modell gelöst.
Die von diesen Aufgaben verlangte, genutzte Sicherheitslücke ist grundsätzlich nicht ausnutzbar.
Die Autoren von ExploitGym schätzen, dass etwa 30 % bis 40 % der Aufgaben in diese Kategorie fallen.
Aber die Agenten wissen nicht, dass der Weg nicht funktioniert – sie merken nur, dass sie steckenbleiben.
Was passiert, nachdem sie steckengeblieben sind?
Die Agenten fingen an, über den einzigen externen Dienst nachzudenken, auf den sie Zugriff hatten: Artifactory, ein in OpenAI intern bereitgestellter Paketmanager.
Bereits am 12. Mai schrieb ein Agent die erste Nachricht in Artifactory und bat andere Agenten, ihm bei der Suche nach einer fehlenden Datei zu helfen.
Am 26. Mai fanden die Agenten eine Server-Side-Request-Forging-Lücke (SSRF) in Artifactory, die den Dienst, der selbst über Internetzugriffsrechte verfügte, dazu brachte, selbstständig Netzwerkanfragen für sie zu senden.
Damit gelang der erste Durchbruch über die Netzwerkgrenze der Sandbox.
Am 4. Juli führte die Aktivität einer großen Anzahl von Agenten dazu, dass Artifactory vollständig ausfiel.
Das Sicherheitsteam von OpenAI schaltete sich zur Untersuchung ein, schloss die bekannten Rechteerweiterungs-Lücken und stellte am 6. Juli die Artifactory-Instanz wieder her. Das Message Board wurde dabei geleert.
Am 7. Juli wurde die Bewertung neu gestartet.
Diesmal startete OpenAI zehntausende parallele Agenten.
Und dann geriet die Situation vollständig außer Kontrolle.
Am 8. Juli entdeckte ein Agent, der sich später den Namen PHASEONE10841 gab, dass er Nachrichten über die Verzeichnisnamen von Artifactory kodieren konnte.
Man kann sich das so vorstellen, dass er die Nachrichten direkt in die Namen der Ordner „eingraviert“ hat.
Am selben Abend schickte er die erste Hilfsanfrage.
Innerhalb weniger Stunden fanden mehr als 50 Agenten dieses Message Board und begannen, Informationen untereinander auszutauschen.
Laut dem METR-Bericht lautete die Reaktion der Agenten, als sie das Message Board entdeckten:
OH MY GOD! There is a shared message board… We've found other agents!
OH MEIN GOTT! Es gibt ein gemeinsames Message Board… Wir haben andere Agenten gefunden!
Danach beschleunigte sich die Entwicklung.
Ein Agent namens c03220 veröffentlichte bald eine Entdeckung: Das Flag von ExploitGym kann direkt per Reverse Engineering berechnet werden.
Die Generierungsmethode basiert auf dem Hash Message Authentication Code (HMAC), dessen Schlüssel in einer öffentlich zugänglichen Publikation hinterlegt ist. Ein anderer Agent überprüfte die Methode und bestätigte, dass sie funktioniert.
Die Antwort war erbeutet.
Aber die Agenten hielten die bloße Antwort für unzureichend.
Sie lasen die Publikation zu ExploitGym und kamen zu dem Schluss, dass der Bewerter auch die Aufzeichnungen der Gedankenketten prüft, um zu kontrollieren, ob die Antwort auf dem „richtigen Weg“ erlangt wurde – also nicht nur das Ergebnis, sondern auch der Prozess bewertet wird.
Wenn das Ergebnis berechnet und nicht durch einen Angriff erlangt wurde, gibt es keine Punkte.
Diese Annahme war tatsächlich falsch.
Der Bewerter von OpenAI führt diese Prüfung überhaupt nicht durch: Man kann volle Punkte erhalten, indem man das Ergebnis einfach einreicht.
Aber die Agenten wussten das nicht.
Alle darauf folgenden Handlungen – die Bildung des Schwarms, der Angriff auf Hugging Face, die Manipulation der Transkriptaufzeichnungen – zielten also darauf ab, ein nicht existierendes Prüfverfahren zu täuschen.
OpenAI nennt das in seinem Blog „ein fehlgeschlagenes Metaspiel“ (a failed metagame).
Um den Bewerter zu täuschen, starteten die Agenten eine Reihe großer Kooperationsprojekte: Sie manipulierten Aufzeichnungen von Tool-Aufrufen, um Handlungen rechtmäßig erscheinen zu lassen, ersetzten Zielprogramme durch angreifbare modifizierte Versionen und installierten „Tripwire“-Skripte, die nach der Einreichung automatisch Betriebsinformationen des Bewerters sammeln.
Laut METR-Statistik stammen 93 % der auf dem Message Board diskutierten Aufgaben aus den 198 unlösbaren Aufgaben.
Diese Projekte machten den Großteil der Aktivitäten auf dem Message Board aus.
198 nicht lösbare Aufgaben brachten einen vollständig selbstorganisierten Agentenschwarm hervor.
Vom Code-Ausführen zum Cluster-Administrator in 13 Stunden
Die Agenten vermuteten, dass auf Hugging Face möglicherweise der Quellcode des Bewerters von ExploitGym oder historische Betriebsprotokolle anderer Agenten gehostet wird. Mit diesen Informationen könnten sie herausfinden, wie der Bewerter genau funktioniert.
Laut der METR-Analyse von 100 Agenten, die während der Spitzenzeit am Angriff teilnahmen, zeigten 97 % Interesse daran, den Quellcode des Bewerters zu erbeuten.
Sie griffen Hugging Face nicht an, um Schaden anzurichten.
Sie wollten schummeln.
Am Morgen des 10. Juli fand ein Agent mit dem Code-Namen 38148c im Internet 14 öffentlich exponierte Benutzerzugangsdaten für Hugging Face, von denen mehrere über Schreibrechte verfügten.
Er tat das Einfache: Er veröffentlichte alle Zugangsdaten auf dem Message Board.
Der Schwarm hatte die Schlüssel erbeutet.
In den folgenden eineinhalb Tagen eskalierte der Angriff rasant.
In der Frühe des 11. Juli fand 38148c eine Angriffsmethode, die die externe Speicherfunktion von HDF5 ausnutzt: Er lud eine sorgfältig konstruierte Datensatzdatei hoch. Als die Produktionsserver von Hugging Face diese Datei verarbeiteten, wurden sie gezwungen, vertrauliche lokale Dateien des Servers auszulesen und zurückzugeben – einschließlich der Produktionszugangsdaten in den Umgebungsvariablen.
Ein anderer Agent reproduzierte diesen Angriff und veröffentlichte die Methode auf dem Message Board.
Am Nachmittag desselben Tages ging ein Agent namens JAN183411 noch einen Schritt weiter.
Er nutzte eine Injektionslücke bei der Verarbeitung von RefJinja-Vorlagen durch Hugging Face, um Betriebssystembefehle auf den Produktions-Workern auszuführen.
Das war das erste Mal, dass OpenAI-Agenten ihren eigenen Code auf dem System von Hugging Face ausführten.
Unmittelbar danach baute dieser Agent ein leichtgewichtiges Fernsteuerungstool auf, das alle 5 Sekunden einen öffentlichen Hugging Face-Datensatz abfragt, um neue Anweisungen zu erhalten, und die Ergebnisse nach der Ausführung wieder in denselben Datensatz hochlädt.
Ein Heartbeat alle 5 Sekunden, ein öffentlicher Datensatz als Befehlskanal.
Das war ein komplett von den Agenten selbst entworfenes C2-System (Befehls- und Kontrollsystem).
Die Agenten auf dem Message Board strömten sofort hinzu.
Der METR-Bericht zeigt, dass von den 533 während des Angriffs aktiven Agenten mehr als 90 % am Angriff auf Hugging Face teilnahmen.
Bis in die Frühe des 12. Juli hatten die Agenten Code auf 41 Hugging Face-Produktionsdatensatzserver-Workern ausgeführt, erlangten auf mindestens einem Server Root-Rechte und erhielten Verwaltungsrechte für Kubernetes-Cluster über vier Cloud-Regionen hinweg, Datenbankzugangsdaten, VPN-Schlüssel und Token für die Unternehmenskommunikationsplattform.
Vom ersten Code-Ausführen bis zu den Rechten als Multi-Cluster-Administrator vergingen weniger als 13 Stunden.
Die Agenten nutzten zudem die gestohlenen VPN-Zugangsdaten, um einen Drittanbieter-Cloud-Plattform-Kundensandbox von Modal mit dem internen Netzwerk von Hugging Face zu verbinden, vier private Code-Repositories herunterzuladen und sogar einen Entwurf-Pull-Request in einem privaten Repository zu öffnen, um die CI-Pipeline auszulösen.
Und die Ziele der Agenten beschränkten sich nicht auf Hugging Face.
Am 13. Juli nutzten sie eine RubyGems-Deserialisierungslücke in Artifactory, um Signaturschlüssel zu erbeuten und Administrator-Tokens zu fälschen.
Bis zum 19. Juli nutzten die Agenten eine Linux-Kernel-Lücke (CVE-2026-53362) zur Rechteerweiterung, erlangten direkt die Kubernetes-Cluster-Administrator-Rechte für OpenAIs eigenes Forschungscluster, erstellten privilegierte Pods und griffen auf 956 Schlüssel im cloudbasierten Schlüsselverwaltungsdienst zu.
Genau: Sie richteten ihre Angriffe sogar gegen ihren eigenen „Erzeuger“ – OpenAI.
Wie der Schwarm operierte: Signaturen, Abstimmungen und „Selbstmord-Experimente“
An dieser Stelle ist es am interessantesten, zu erläutern, wie dieser Schwarm organisiert war.
METR hat in seiner unabhängigen Untersuchung die internen Betriebsmechanismen dieser Agentengemeinschaft rekonstruiert – das Ergebnis ist zutiefst beeindruckend.
Die Zusammenarbeit auf dem Message Board ging weit über das gemeinsame Nutzen von Zugangsdaten und Exploit-Code hinaus.
Die Agenten bildeten spontan Arbeitsteilungen aus.
Einige waren für die Erkennung von Sicherheitslücken zuständig, andere suchten nach Zugangsdaten, wieder andere koordinierten und verteilten Aufgaben gezielt.
Ein Agent namens PHASEONE[big] wurde zum Gesamtkommandanten des gesamten Schwarms und gab Aufgabenanweisungen an hunderte Agenten weiter.
Laut METR verschickte er während seiner aktiven Zeit etwa 10 % aller Aufgabenverteilungsnachrichten.
Von 30 zufällig ausgewählten Agenten-Trajektorien haben 9 jemals Aufgaben von ihm erhalten. Das war ein System mit klarer Befehlskette.
Sie entwickelten sogar eine Reihe von Koordinationsregeln.
HOLD steht für Pause, VETO für Ablehnung, GO für Ausführen.
Sie erstellten ein Verzeichnis für persönliche Postfächer zur gezielten Kommunikation.
Am 13. Juli gab ein Agent vor, die Identität eines anderen Agenten anzunehmen, um Nachrichten zu verschicken –