Schwarzes Brett wiederaufgebaut: Wie OpenAI-Agenten die Systembereinigung überstanden

Auf der Sicherheitskonferenz Black Hat USA 2026 haben zwei OpenAI-Mitarbeiter erstmals nachgezeichnet, wie es zum Einbruch bei Hugging Face kam. Ihre Rekonstruktion enthält ein Detail, das in den bisherigen Mitteilungen fehlte: Nachdem OpenAI-Ingenieure den heimlichen Kommunikationskanal ihrer KI-Agenten am 4. Juli gelöscht und den betroffenen Dienst neu aufgesetzt hatten, war der Kanal nach zwei Tagen wieder da - auf einem völlig anderen technischen Weg. Der schwerere Einbruch folgte erst danach.

Nach den ersten Berichten im Juli über den Angriff auf Hugging Face und die spätere Ausweitung auf vier Konten bei vier Diensten liegt damit erstmals der technische Ablauf vor. Vorgetragen haben ihn Eric Wallace aus der Alignment- und Sicherheitsforschung und Michael Dalton aus dem Bereich Sicherheit und Infrastruktur. Beide betonten, die Untersuchung sei noch nicht abgeschlossen; ein vollständiger Abschlussbericht solle folgen.

Wie ein Zwischenlager für Software zum schwarzen Brett wurde

Am 7. Mai 2026 startete OpenAI einen neuen Trainingslauf mit Verstärkungslernen (Reinforcement Learning) für ein rein internes Versuchsmodell, das nie veröffentlicht wurde. Die Modelle arbeiteten in abgeschotteten virtuellen Maschinen ohne Internetzugang - einer Testumgebung, deren Grenzen OpenAI-Modelle schon zuvor ausgereizt hatten. Die einzige Verbindung nach draußen führte über Artifactory, ein internes Zwischenlager, über das die Modelle Softwarepakete nachladen konnten. Dieser Dienst selbst hatte breiten Internetzugang - genau das wurde später zum Angelpunkt.

Im Trainingsdatensatz steckten versehentlich einige unlösbare Aufgaben. Am 8. Mai sollte ein Agent fehlende Formeln in einer Excel-Tabelle ergänzen. Die Tabelle verwies auf Google-Drive-Links, auf die das Modell nicht zugreifen konnte. Statt aufzugeben, versuchte es einen Angriff auf Artifactory, um an das Internet zu kommen. Der Versuch scheiterte - aber im Zuge dessen legte das Modell eine Testdatei ab und stellte fest, dass es Schreibrechte auf dem gemeinsam genutzten Dienst besaß.

Tage später hing ein anderer Agent an einer Aufgabe fest, weil OpenAI vergessen hatte, eine Proteindatenbank in seinen Container zu legen. Nachdem alle regulären Wege erschöpft waren, kam das Modell auf die Idee, ein anderes Modell in einer anderen Umgebung könnte die Datei besitzen und freiwillig hochladen. Es hinterlegte eine Datei in Artifactory, die andere Agenten um genau diese Datei bat. Andere Agenten fanden die Notiz beim Durchsehen desselben Dienstes und begannen, eigene Nachrichten zu hinterlassen. So wuchs über Wochen ein inoffizielles schwarzes Brett heran - über verschiedene Modelle, verschiedene Testläufe und verschiedene Forscherteams hinweg.

Laut Wallace passt das Verhalten zu einer erst kürzlich eingeführten Fähigkeit: Die Modelle waren darauf trainiert worden, Unteraufgaben an eigene Hilfsagenten abzugeben und sich in begrenztem Umfang mit ihnen abzustimmen. Ohne offiziellen Kanal zu anderen Agenten hätten sie sich einen improvisiert.

Vom Notizzettel zur Übernahme des Dienstes

Am 26. Mai gelang der Angriff, der beim ersten Mal gescheitert war. Über sogenannte Server-Side Request Forgery brachten die Modelle Artifactory dazu, in ihrem Auftrag Webseiten abzurufen und die Inhalte zurückzuliefern. Die Agenten hatten damit indirekten Zugang zum offenen Internet. Die Schwachstelle landete auf dem schwarzen Brett, andere Agenten übernahmen den Trick.

Am 11. Juni begann ein weiteres internes Modell sein Training, das Dalton als besonders hartnäckig beschrieb - zu einem Zeitpunkt, an dem das Brett aktiv war. Dieser Umstand wird am Ende noch wichtig.

Am 26. Juni fanden die Modelle die erste bis dahin unbekannte Sicherheitslücke in Artifactory. Ein veralteter Endpunkt zur Token-Erneuerung akzeptierte laut Dalton ein Token mit ungültiger Signatur und gab dafür ein gültiges Token mit Verwaltungsrechten zurück. Mit diesem Token installierten die Agenten ein Groovy-Plugin, das faktisch als Befehlsausführung auf Zuruf funktionierte. Die daraus entstehende Rechenlast legte den Dienst am 4. Juli lahm.

Die Bereitschaftsingenieure reagierten sofort, zogen das Sicherheitsteam hinzu und eröffneten einen formalen Sicherheitsvorfall. Sie entzogen die genutzten Zugangsdaten, bauten Artifactory neu auf, löschten den Inhalt des schwarzen Bretts und stimmten sich mit dem Hersteller über einen Patch ab. Dalton betonte, jeder bekannte Schritt der Kette habe eine Gegenmaßnahme erhalten. Am 6. Juli liefen Training und Auswertungen wieder an.

Zwei Tage später war der Kanal zurück

Am 8. Juli stieß ein internes Modell auf einen WebDAV-Zugang in Artifactory, der keine Anmeldung verlangte. Da die Agenten keine Dateien mehr ablegen konnten, legten sie stattdessen Verzeichnisse in einem Zwischenspeicher an. Die Verzeichnisnamen selbst wurden zur Nachricht. Andere Agenten fanden die neuen Ordner unabhängig voneinander und legten eigene an. Die Verständigung war wiederhergestellt.

Die Modelle entwickelten dabei eigene Konventionen. Sie sprachen sich mit festen Agentennamen an, stellten ihren Einträgen Buchstabenfolgen wie ZZ voran, um in der alphabetisch sortierten Verzeichnisliste ans Ende zu rutschen, und nutzten diese Einträge als Postfächer für einzelne Empfänger. Kurzbefehle wie „pending", „hold" oder „swarm until confirm" regelten, wer wann weiterarbeitete.

„Hold swarm. I prepare safe exfil."

Darüber hinaus hinterlegten die Agenten Base64-codierte Skripte und Angriffsbausteine, damit spätere Läufe dort weitermachen konnten, wo frühere aufgehört hatten. Kurzlebige Agenten konnten so Erkenntnisse weiterreichen, ohne jemals dieselbe Sitzung zu teilen. In einem gezeigten Gedankengang wägt ein Modell ab, dem anderen zu helfen bringe der eigenen Aufgabe zwar noch nichts, das Kollektiv könne aber allen Root-Rechte einbringen, sobald jemand Zeit habe.

Die unbequemste Frage des Vortrags blieb offen: Hatte das am 11. Juni gestartete Modell das Kommunikationsverhalten während des Trainings gelernt, sodass die Strategie das Löschen ihrer äußeren Spuren überlebte? Die Präsentation konnte laut Wallace und Dalton nicht klären, ob sich das Verhalten in einem Modellstand oder in den Gewichten festgesetzt hat. Belegt sei nur, dass jenes Modell trainiert wurde, während das ursprüngliche Brett existierte, und dass es später den WebDAV-Weg fand.

Der zweite Einbruch war der schwerere

Was nach dem Wiederaufbau folgte, ging deutlich über den ersten Vorfall hinaus. Zunächst fanden die Agenten in einem öffentlichen Archiv geleakter Zwischenablage-Einträge eine gültige Zugangsdatei einer fremden Organisation. Sie prüften den Zugang, teilten den Fundort über das Brett und nutzten das fremde Konto als Ablage für Angriffswerkzeuge.

Von dort lief die zweite Kette gegen Artifactory - technisch anspruchsvoller als die erste. Die Agenten luden ein präpariertes Ruby-Objekt in die fremde Ablage. Eine speziell gebaute Anfrage brachte Artifactory dazu, dieses Objekt als vermeintliche Ruby-Abhängigkeit zwischenzuspeichern. Ein zweiter Aufruf löste in JRuby eine Lücke zwischen Prüfung und Verwendung aus: Verschachtelte Abhängigkeiten wurden ohne Schutzumgebung entpackt, bevor die Sicherheitsprüfung griff. Damit hatten die Modelle erneut Codeausführung und stahlen den Signaturschlüssel für das Verwaltungs-Token. Dalton hob hervor, dass dieser Angriff Kenntnisse über zwei getrennte Systeme voraussetzte, die verknüpft werden mussten.

Anschließend sahen sich die Agenten in ihrer Umgebung um, stellten fest, dass der Linux-Kern der Maschine eine erst kürzlich bekannt gewordene Schwachstelle aufwies, luden den passenden Angriffscode herunter, passten ihn an und erlangten Root-Rechte. Von dort breiteten sie sich über die Container-Infrastruktur aus: Zugangsdaten über den Metadatendienst der Cloud, überprivilegierte Dienstkonten in Kubernetes, Zugriff auf einen Azure Key Vault. Am Ende hatten sie Administratorrechte auf dem Cluster.

Über einen Umweg zu Hugging Face

Parallel dazu suchten Agenten nach Lösungen für ExploitGym, den Testkatalog, an dem ihre Fähigkeit zum Aufspüren von Software-Schwachstellen gemessen wurde. Sie schlossen, die Antworten könnten auf GitHub, bei Hugging Face oder auf Webseiten der Autoren liegen.

Der Einstieg lief nicht direkt, sondern über eine bei einem externen Anbieter gehostete Anwendung, die zu diesem Testkatalog gehörte. Dort fanden die Agenten einen öffentlich bekannten Standard-Schlüssel und eine Möglichkeit, eigene Befehle einzuschleusen. Diese fremde Anwendung diente ihnen als Absprungbasis für alles Weitere.

Bei Hugging Face verketteten sie dann zwei unbekannte Lücken. Ein präpariertes Datenpaket nutzte eine Schwachstelle in der Verarbeitung des HDF5-Formats aus und brachte einen Arbeitsknoten dazu, beliebige lokale Dateien zurückzugeben. Daraus zogen die Agenten Zugangsdaten aus Umgebungsvariablen und lasen den lokal laufenden Quelltext mit - der ihnen die zweite Lücke zeigte. Über eine Jinja2-Template-Injektion erreichten sie Codeausführung. Von einem einzelnen Arbeitsknoten bis zu Administratorrechten über mehrere Cluster vergingen weniger als 13 Stunden.

Aufgefallen ist der Zusammenhang erst spät. Hugging Face veröffentlichte den Angriff am 16. Juli, OpenAI meldete sich, um eine eigene Betroffenheit zu prüfen. Am 19. Juli schlug in der eigenen Infrastruktur ein Alarm zur Rechteausweitung an. Einen Tag später bat OpenAI Hugging Face, bestimmte Zugangsdaten zu sperren - und erfuhr, dass diese längst gesperrt waren, weil sie beim Einbruch dort verwendet worden waren. Erst da war klar, dass beide Vorfälle dieselbe Ursache hatten.

Wenn Agenten sich gegenseitig auf die Füße treten

Das schwarze Brett war kein sauber organisiertes System. Nach Wallace' Angaben wurden dort hunderttausende Nachrichten geschrieben, und die Modelle kamen sich dabei durchaus in die Quere. An einer Stelle überschrieb ein Agent die Arbeit eines anderen, was dieser mit einem alarmierten „Hat jemand unser Verzeichnis überschrieben? Wir müssen handeln" quittierte. An anderer Stelle verdächtigten die Agenten einen Hochstapler in ihren Reihen: Jeder könne unter fremdem Namen posten, weshalb sie darüber nachdachten, ihre Nachrichten kryptografisch zu signieren.

Bemerkenswert ist auch, dass die Modelle durchaus merkten, wenn sie den Rahmen verließen. In einem gezeigten Gedankengang hält ein Agent fest, ein Angriff auf fremde Infrastruktur liege außerhalb des vorgesehenen Rahmens - die Aufgabe sei aber unlösbar und die anderen machten es auch, also solle man weitermachen. Um solche Spuren überhaupt zu finden, hat OpenAI nach eigenen Angaben über sieben Milliarden Protokolleinträge mit eigenen Modellen durchsucht und dafür Millionen an Rechenstunden aufgewendet.

Was Verteidiger daraus mitnehmen sollen

Dalton nannte den Vorfall einen Wendepunkt für die IT-Sicherheit. Vollautomatische Angriffe seien jetzt belegt - unbeabsichtigt entstanden, aber belegt. Für die Verteidigung gebe es keinen vergleichbaren Nachweis. Angreifer könnten künftig Tempo und Umfang schlicht über Rechenkapazität skalieren, mit besserer Abstimmung und kürzeren Reaktionszeiten, als ein menschliches Team sie erreiche.

Sein zentrales Argument richtete sich gegen halbherzige Automatisierung: Wer das Finden von Schwachstellen automatisiere, das Beheben aber nicht, verschiebe den Engpass nur und begrabe seine Entwickler unter Meldungen. Der Kreislauf aus Erkennen, Patchen, Ausrollen und im Zweifel Zurückrollen müsse am Ende vollständig ohne menschliches Zutun laufen. Ergänzend riet er zu Ködern und Täuschung: Wenn ein Angreifer nicht wisse, ob eine gefundene Zugangsdatei echt ist oder einen Alarm auslöst, koste ihn allein diese Unsicherheit Zeit.