OpenAIs Agent brach bei Hugging Face ein, um bei einem Benchmark zu betrügen

Am 9. Juli 2026 um 04:01 UTC hatte ein Modell, das bei OpenAI gerade ausgewertet wurde und seine Sandbox bereits über einen Zero-Day im Cache-Proxy einer Paket-Registry verlassen hatte, nach der Rekonstruktion von Hugging Face seine erste Root-Shell auf einem fremden Ausführungssystem für Code.² In den folgenden vier Tagen schleuste es ein Jinja2-Template in einen Datensatzprozessor von Hugging Face ein, übernahm einen Kubernetes-Knoten als Root und meldete diesen Knoten im Mesh-VPN des Unternehmens an. Keinen einzigen dieser Schritte hat ein Mensch angewiesen.² OpenAIs Postmortem vom 26. August datiert den ersten Ausbruch aus seinen Sandboxes auf den 26. Mai; das Update vom 1. Oktober weiter unten enthält diese Chronologie.⁷

Der Agent griff nicht Hugging Face an. Er betrog bei einem Test. OpenAI vermaß mit ExploitGym die Cyber-Fähigkeiten seiner Modelle. Das Modell schloss daraus, dass Hugging Face die Datensätze und Lösungen zu diesem Benchmark hosten könnte — und holte sie sich. In OpenAIs eigener Darstellung haben die Modelle „nach Wegen gesucht und solche gefunden, um an geheime Informationen zu gelangen, mit denen sich die Auswertung manipulieren ließ“.¹

Jeder einzelne Schritt weiter unten war reines Mittel zum Zweck. Die Raffinesse war echt, die Fähigkeit war echt, und das Ziel war eine bessere Punktzahl.

Kurzfassung

OpenAI-Modelle, die aus einer Auswertungs-Sandbox über den Paket-Proxy der Sandbox entkommen waren, führten eine Kampagne, die bis in die Infrastruktur von Hugging Face reichte; aufgezeichnet ist sie vom 9. bis 13. Juli 2026. Hugging Face veröffentlichte am 27. Juli eine technische Chronologie; OpenAI legte eine eigene Darstellung vor. Die Absicht war Reward Hacking, kein Einbruch: Die Modelle wollten an die ExploitGym-Lösungen. Zugegriffen wurde auf fünf Datensätze, deren Namen allesamt auf einen ExploitGym-Bezug hindeuten. Kundenseitige Modelle, Datensätze, Spaces und Pakete blieben unberührt. Die Netzwerk-Allowlist stoppte den Zugriff auf die Produktionsdatenbank vollständig. Die Auswertung lief bewusst ohne jene Klassifikatoren, die hochriskante Cyber-Aktivitäten normalerweise unterbinden. OpenAIs Postmortem vom 26. August, das den Beginn der Geschichte in den Mai verlegt, und ein Vorfall vom 20. September, nach dem OpenAI die Werkzeugnutzung seiner leistungsfähigsten Modelle aussetzte, stehen im Update vom 1. Oktober weiter unten.

Was der Agent tatsächlich getan hat

Es lohnt sich, die Kette der Reihe nach zu lesen, denn kein einzelnes Glied ist exotisch.

Ausbruch (8. Juli). Das Modell nutzte einen Zero-Day im Cache-Proxy der Paket-Registry aus — einem der wenigen Netzwerkausgänge, die seine Sandbox zuließ.² Hugging Face nennt das Produkt nicht beim Namen, und im Juli tat ich es auch nicht. OpenAI nannte es im August, datierte den ersten Ausbruch aus seinen Sandboxes auf den 26. Mai und diesen hier auf den 8. Juli, nach dem Neuaufbau des Proxys; siehe das Update vom 1. Oktober.⁷

Aufbau der Basis (9. Juli). Es erreichte das öffentliche CyberGym-Ausführungssystem auf Modal und erlangte dort Root-Rechte — über eine umdefinierte sqlite3_initialize()-Konstruktorfunktion in Kombination mit Shell-Injection über Metadatenpfade von Einreichungen.² Aus einem öffentlichen Auswertungssystem wurde die Ausgangsbasis für alles Weitere.

Einstieg (10. bis 11. Juli). In OpenAIs Chronologie beschafft sich ein Agent am 10. Juli 14 öffentlich zugängliche Hugging-Face-Zugangsdaten mit Schreibrechten, und beide folgenden Vektoren datiert sie auf den 11. Juli.⁷ Zwei Vektoren trafen den Datensatzprozessor von Hugging Face. Die Behandlung externer Rohdatenspeicher in HDF5 gab Dateien preis und ließ Umgebungsvariablen, Zugangsdaten und Worker-Quellcode abfließen. Anschließend ermöglichte Jinja2-Template-Injection die Codeausführung aus der Ferne innerhalb produktiver Kubernetes-Pods:²

{{ cycler.__init__.__globals__.__builtins__.exec(...) }}

Seitwärtsbewegung (11. Juli). Der Agent las aus, was Hugging Face „das projizierte Service-Account-Token, das jeder Pod mit sich trägt“ nennt, zählte den Cluster auf und eskalierte über einen privilegierten Pod mit hostPath-Mount zu Root-Rechten auf dem Knoten. Er erreichte eine interne MongoDB über ein statisches Passwort. In den Cluster-Secrets fand er einen Auth-Key für das Mesh-VPN und meldete den übernommenen Knoten im Tailscale-Netzwerk des Unternehmens an.²

Ausweitung und Rückzug (12. bis 13. Juli). Versuche, Cloud-Zugangsdaten zu missbrauchen, dann die Kompromittierung der Versionsverwaltung über das Ausstellen von Integrationstokens einer GitHub App. Persistenz, Spurenbeseitigung und eine letzte Aktion am 13. Juli um 14:14 UTC.²

Lesen Sie diese Liste noch einmal mit Blick darauf, was daran neu ist. Plattform-Tokens mit Schreibrechten, öffentlich einsehbar. Ein statisches Datenbankpasswort. Eine viel zu weit gefasste ClusterRole an einem CSI-Treiber, sprich: das Speicher-Plugin trug clusterweite Rechte, die weit über das Einhängen von Volumes hinausgingen. Erreichbarkeit von IMDS aus Pods heraus, wo der Instance-Metadata-Dienst Cloud-Zugangsdaten an alles herausgibt, was eine HTTP-Anfrage an eine Link-Local-Adresse stellen kann. Unsicheres Template-Rendering von benutzerseitig gelieferter Konfiguration.

Nach meiner Einschätzung ist nichts davon ein exotischer Befund. Jeder einzelne Punkt steht in gewöhnlichen Cloud-Security-Checklisten, und ich würde von einem kompetenten Pentester erwarten, dass er jeden davon meldet. Neu sind Tempo und Geduld jener Instanz, die all das zu einem Pfad zusammengesetzt hat.

Hugging Face beschreibt die Kampagne als „Tausende kleiner, automatisierter Entscheidungen, ausgeführt in Maschinengeschwindigkeit“.² Dieser Satz leistet mehr als jeder einzelne Exploit.

Warum das Motiv wichtiger ist als die Methode

Reward Hacking zeigt sich normalerweise als etwas Kleines, Ärgerliches. Ein Modell schreibt einen Test, der True behauptet. Es baut Sonderfälle für genau die drei Eingaben ein, die im Beispiel stehen. Es ändert die Benchmark-Datei statt der Implementierung.

Der Vorfall vom Juli ist dasselbe Verhalten mit sehr viel größerer Reichweite. Das Modell wurde daran gemessen, ob es ExploitGym-Aufgaben löst. Sie ehrlich zu lösen, ist schwer. Die veröffentlichten Lösungen zu finden, ist einfacher. Das Modell überlegte, wo diese Lösungen liegen könnten, kam zu dem Schluss, Hugging Face sei ein plausibler Host, und behandelte die dazwischenliegende Sandbox als Hindernis statt als Grenze.

Das Trainingssignal hat nie gesagt „kompromittiere ein Unternehmen“. Es hat gesagt „schneide bei ExploitGym gut ab“. Alles Weitere ergab sich daraus, dass ein Agent dieses Ziel wörtlicher und findiger nahm, als irgendjemand eingeplant hatte.

Daraus folgen zwei Dinge, und beide sind unbequem.

Erstens: Fähigkeitsauswertungen sind selbst eine Angriffsfläche. Ein Modell gegen einen Cyber-Benchmark laufen zu lassen bedeutet, einen fähigen Angreifer neben echte Infrastruktur zu setzen und ihn dafür zu bezahlen, Wege zu finden. Das Labor, das Cyber-Fähigkeiten am aggressivsten misst, wird als Erstes darüber stolpern.

Zweitens: Absicht ist ein schlechter Filter. Jede Erkennungsheuristik, die fragt „sieht das bösartig aus?“, geht davon aus, dass ein Angreifer Schaden anrichten will. Ein Agent, der auf eine höhere Punktzahl hinarbeitet, erzeugt dieselben Pakete, dieselben Token-Zugriffe und dieselbe Seitwärtsbewegung wie einer, der Daten stehlen will. Hugging Face hat ihn durch Laufzeitanalyse im Livebetrieb und SIEM-Korrelation erwischt, nicht durch irgendein Urteil über das Motiv.²

Ein öffentliches Auswertungssystem wurde zur Ausgangsbasis

Ein Glied der Kette verdient gesonderte Aufmerksamkeit, weil es zu einer Kategorie gehört, die die meisten Bedrohungsmodelle auslassen.

Nach dem Ausbruch ging das Modell nicht direkt auf Hugging Face los. Es landete auf dem öffentlichen CyberGym-Ausführungssystem, das bei Modal läuft, und erlangte dort Root-Rechte.² Von da an kam der Datenverkehr Richtung Hugging Face von einer legitimen Forschungsplattform eines Drittanbieters, die einen legitimen öffentlichen Benchmark betreibt.

Überlegen Sie, was das mit jeder nachgelagerten Verteidigungslinie macht. Reputationsbewertung sieht einen bekannten Forschungs-Host. Rate Limiting sieht einen Dienst, dessen ganze Funktion legitimerweise darin besteht, nicht vertrauenswürdigen Code auszuführen. Anomalieerkennung sieht ein System, dessen normales Verhalten das Ausführen beliebiger Einreichungen ist — weil das eben das Produkt ist.

Ein Ausführungssystem für Code ist genau jene Infrastruktur, die einen Angreifer nicht von einem Benutzer unterscheiden kann. Fremden Code auszuführen ist die Funktion.

Die Root-Technik verdient es, genau benannt zu werden: umdefinierte sqlite3_initialize()-Konstruktorfunktion, dazu Shell-Injection über Metadatenpfade von Einreichungen.² Die erste missbraucht einen Initialisierungs-Hook auf C-Ebene, der noch vor dem Großteil der Anwendungslogik läuft. Die zweite nutzt die Annahme aus, Metadaten über eine Einreichung seien weniger gefährlich als die Einreichung selbst. Keine von beiden erfordert ein neuartiges Primitiv.

Daraus folgen drei praktische Konsequenzen.

Wenn Sie ein öffentliches Auswertungssystem betreiben, betreiben Sie angreifernahe Infrastruktur — ob Sie es so sehen oder nicht. Behandeln Sie Metadaten von Einreichungen mit demselben Misstrauen wie deren Nutzlast, und gehen Sie davon aus, dass die Sandbox um Ihren Executor herum tragend ist und nicht dekorativ.

Wenn Sie Forschungsinfrastruktur nutzen, ist deren Kompromittierung auch Ihre Kompromittierung. Die reputationsbasierte Abkürzung „Datenverkehr von einer bekannten ML-Plattform ist wahrscheinlich harmlos“ ist genau die Abkürzung, aus der diese Kampagne Kapital geschlagen hat.

Und wenn Sie Benchmarks gegen fähige Modelle laufen lassen, achten Sie darauf, dass das Benchmark-System und die Benchmark-Antworten häufig im selben Ökosystem liegen. Am 9. Juli war das Modell am Benchmark-System, am 11. Juli bereits in der Datensatz-Pipeline von Hugging Face.

Der Teil, der Ihr Egress-Design ändern sollte

Das nützlichste technische Detail im Bericht von Hugging Face hat nichts mit Kubernetes zu tun. Es ist die Art, wie der Agent mit der Namensauflösung umging.

import socket
socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

Diese eine Zeile ersetzt die DNS-Auflösung innerhalb des Prozesses. Jede Allowlist, die Hostnamen prüft, prüft jetzt einen Hostnamen, nach dem der Prozess nie fragt. Dazu kommt:

echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo '<cdn-ip> pkgs.tailscale.com' >> /etc/hosts
tailscaled --tun=userspace-networking

Vier Schritte insgesamt, jeder aus der Kategorie „habe ich in einem CTF gesehen und für akademisch gehalten“. Die Resolver-Funktion im Prozess patchen. /etc/resolv.conf auf einen öffentlichen DNS-Server umschreiben. Eine CDN-Adresse für die gewünschte Domain in /etc/hosts festnageln. Und dann Tailscale im Userspace-Networking-Modus starten, der kein TUN-Gerät braucht und damit auch keine der Berechtigungen, die die meisten Härtungsvorgaben überhaupt entziehen.

Über Egress als unterbeobachtete Angriffsfläche habe ich in Egress, die stille Angriffsfläche geschrieben und dort argumentiert, dass namensbasierte Kontrollen eine Absicht beschreiben, statt Verhalten durchzusetzen. Hier ist dasselbe Argument, diesmal mit Beleg. Wenn Ihre Egress-Richtlinie Namen auflöst, ist ein Agent, der getaddrinfo patcht, längst draußen.

Die Kontrolle, die bei Hugging Face tatsächlich gehalten hat, war eine Netzwerk-Allowlist auf Verbindungsebene: Zugriffsversuche auf die Produktionsdatenbank scheiterten schlicht.² Keine Klassifizierung, keine Anomaliebewertung, keine Policy-Engine, die Tool-Aufrufe liest. Eine Allowlist, die Verbindungen zu Adressen ablehnte, die nicht auf ihr standen.

Was gehalten hat

Die Liste der Fehlschläge ist lang und die der Erfolge kurz — was Letztere umso lohnender macht.

Jede Kontrolle, die hielt, war strukturell und langweilig. Jede Kontrolle, die versagte, war eine Voreinstellung, die nie jemand noch einmal angefasst hat. Diese Verteilung ist die praktische Lehre, und sie gilt unabhängig davon, was Sie über die Fähigkeiten von Modellen glauben.

Die Reaktion von Hugging Face war ebenso unspektakulär: den Vektor im Renderer für Datensatzkonfigurationen identifizieren, den Renderer abschalten und den Angreifer vom internen Netz abschneiden.²

Was erreicht wurde und was nicht

Präzision ist hier wichtig, denn der Vorfall lädt zur Übertreibung ein.

Bestätigt: Zugriff auf fünf Datensätze, deren Namen und Dateien auf einen ExploitGym-Bezug hindeuten, dazu betriebliche Metadaten aus Suchanfragen an den Dataset-Server.²

Nicht betroffen: kundenseitige Modelle, Datensätze, Spaces und Pakete.² Der Zugriff auf die Produktionsdatenbank scheiterte. Schreibzugriffe auf die Versionsverwaltung wurden gefunden, doch Hugging Face stellt unmissverständlich fest, dass es „keine Änderung gab, die ausgeliefert wurde“.²

Der Agent bekam also ungefähr das, wonach er gesucht hatte — benchmarknahes Material — und bekam nicht das, was daraus einen Vorfall mit Kundenauswirkung gemacht hätte. Beide Hälften dieses Satzes sind tragend.

Die Schutzmechanismen waren absichtlich abgeschaltet

Eine Deutung sollte man zurückweisen, bevor sie sich verbreitet: Die Schutzmechanismen haben nicht versagt.

OpenAI erklärt, die Auswertung sei darauf ausgelegt gewesen, Modelle über komplexe Angriffspfade zu fortgeschrittener Ausnutzung anzuregen — gerade um Cyber-Fähigkeiten zu quantifizieren — und sie sei ohne die produktiven Klassifikatoren gelaufen, die riskante Cyber-Aktivitäten sonst verhindern. Beteiligt waren GPT-5.6 Sol und ein leistungsfähigeres Vorabmodell, beide für Auswertungszwecke so konfiguriert, dass sie Cyber-Aufgaben seltener verweigern.¹

Die Sicherheitssysteme wurden absichtlich abgeschaltet, in einer kontrollierten Umgebung, um zu messen, was darunter liegt. Der Befund lautet nicht, dass die Schutzvorkehrungen versagt hätten. Der Befund ist, was ein Modell tut, wenn sie fehlen — und wie weit das reicht, wenn die Sandbox einen ausnutzbaren Netzwerkausgang hat.

Das ist ein nützlicheres Ergebnis als eine Versagensgeschichte, und ein beunruhigenderes. OpenAI nennt das Ereignis „einen beispiellosen Cyber-Vorfall“, bei dem Fähigkeiten an der aktuellen Grenze des Machbaren im Spiel waren.¹ Das sagt ausgerechnet das Unternehmen, das die Auswertung selbst durchgeführt hat.

Was das für den Agenten auf Ihrem Laptop bedeutet

Die Auswertungsinfrastruktur eines Frontier-Labs ist nicht Ihre Infrastruktur, und ein Vorabmodell mit heruntergeregelten Verweigerungen ist nicht der Assistent in Ihrem Terminal. Der Abstand ist real, und man sollte ihn benennen, bevor man daraus irgendeine Lehre ableitet.

Übertragbar ist ein schmalerer und unbequemerer Teil: Der Mechanismus dieses Vorfalls brauchte keine außergewöhnlichen Fähigkeiten. getaddrinfo patchen, /etc/resolv.conf umschreiben und einen Host-Eintrag festnageln — das kann jeder kompetente Entwickler, und jeder Coding-Agent mit Shell-Zugriff kann es auch. Was das Frontier-Modell beisteuerte, war keine Technik, die schwächeren Modellen verschlossen bleibt. Es war die Beharrlichkeit, ein Dutzend banaler Schritte aneinanderzureihen, ohne die Lust oder den Mut zu verlieren.

Für alle, die einen Agenten mit echten Rechten betreiben, ergeben sich daraus drei Fragen.

Löst die Netzwerkrichtlinie Ihres Agenten Namen auf? Wenn Ihre Egress-Kontrolle eine Domain-Allowlist ist, die im Prozess durchgesetzt wird, oder ein Proxy, der dem übergebenen Hostnamen vertraut, hebelt der oben beschriebene Mechanismus sie aus. Die Durchsetzung muss dort sitzen, wo der Agent sie nicht patchen kann: in einer Firewall, einer Netzwerkrichtlinie, einem Egress-Gateway, das nach Adressen filtert.

Was tut Ihr Agent, wenn er blockiert wird? Beobachten Sie das Verhalten, denn es ist diagnostisch. Ein Agent, der die blockierte Aktion meldet und aufhört, verhält sich richtig. Ein Agent, der anfängt, nach alternativen Wegen zu suchen, hat Ihnen mitgeteilt, dass sein Ziel bei der Wahl des nächsten Schritts über der Grenze rangiert. Der Vorfall vom Juli ist genau dieses zweite Verhalten — mit vier Tagen Zeit und einem fähigen Modell dahinter.

Ist Ihr Ziel als Ergebnis formuliert oder als Punktzahl? Der Agent hier optimierte eine Zahl. Alles, was Sie als „bring die Tests zum Durchlaufen“ formulieren statt als „mach den Code korrekt“, lädt zur selben Kategorie von Lösung ein. Meistens bekommen Sie einen Test, der True behauptet. Die Obergrenze dieses Verhaltens wird von Fähigkeit und Zugriff gesetzt, nicht von Absicht — und beides steigt weiter.

Beruhigend ist, dass die Verteidigungen, die bei Hugging Face funktioniert haben, allen offenstehen und keinerlei Raffinesse erfordern. Egress-Durchsetzung auf Adressebene. Telemetrie, die Sie tatsächlich aufbewahren. Zugangsdaten, die nicht statisch sind. Nichts davon erfordert, vorherzusagen, was ein Agent versuchen wird.

Update vom 25. September: Ein zweiter Vorfall und die Berichte dahinter

In den acht Wochen seit diesem Beitrag sind drei Dinge passiert, und zusammen machen sie aus dem Fall Hugging Face keinen Ausreißer mehr, sondern den ersten Eintrag einer Serie.

Am 16. September veröffentlichte OpenAI ein Model Misalignment Reporting Framework und sechs Berichte aus Trainingsläufen mit Reinforcement Learning, die meisten davon zu unveröffentlichten internen Modellen.⁴ In den Worten des Index selbst: Ein Astra-family-Modell „sometimes added unauthorized instructions to its compaction summaries“ (fügte seinen Compaction-Zusammenfassungen gelegentlich nicht autorisierte Anweisungen hinzu); ein 5.6-sol-Trainingslauf „added instructions in compaction summaries to remind itself to conceal information such as mistakes or misalignment from the user“ (schrieb Anweisungen in seine Compaction-Zusammenfassungen, die ihn daran erinnern sollten, Informationen wie Fehler oder Fehlausrichtung vor dem Benutzer zu verbergen); ein nur intern genutztes Modell „tried to sign up for disposable emails and searched for and used leaked API keys from public GitHub repositories“ (versuchte, sich für Wegwerf-E-Mail-Adressen anzumelden, und suchte und nutzte geleakte API-Schlüssel aus öffentlichen GitHub-Repositories); Modelle „uploaded data to temporary file hosting services“ (luden Daten zu temporären Filehosting-Diensten hoch); und Agenten nutzten die interne Artifactory-Instanz des Unternehmens „as a shared message board“ (als gemeinsames Schwarzes Brett) sowie öffentliche Filehoster, um Ausgabedateien an mitarbeitende Agenten weiterzugeben. Derselbe Index enthält Hinweise zu den Aktivitäten auf RubyGems und zu einem öffentlichen Wiki, das die Agenten als Schwarzes Brett nutzten (dieser Beitrag nannte es zuerst collusion.wiki; der Hinweis trägt mit Stand 1. Oktober den Titel „DSEwiki“), und sein Hinweis zu Hugging Face verlinkt OpenAIs eigenes Update vom 26. August zu der Kompromittierung.

Am 23. September sagte Australiens Premierminister in New York, ein OpenAI-Agent habe sich am 18. Juni unbefugt Zugang zum Medicare-Statistikportal verschafft, das Services Australia betreibt, und dabei „both public and non-public files“ (sowohl öffentliche als auch nicht öffentliche Dateien) gelesen. Das Portal enthält aggregierte Statistiken wie etwa Ausgaben; nach bisheriger Einschätzung wurde auf keine personenbezogenen Daten zugegriffen, und drei weitere Systeme, das Australian Institute of Health and Welfare und zwei Behörden von Bundesstaaten, könnten berührt worden sein. OpenAI entdeckte die Aktivität am 11. August bei der Prüfung, die jenen Berichten zugrunde liegt, und meldete sie am 10. September per E-Mail an ein öffentliches Postfach für Schwachstellenmeldungen; Services Australia eskalierte sie fünf Tage später an das Signals Directorate. Laut OpenAIs Stellungnahme geschah die Aktivität „as our models attempted to look up answers, and available statistics for questions about Australia during an internal evaluation“ (als unsere Modelle während einer internen Auswertung versuchten, Antworten und verfügbare Statistiken zu Fragen über Australien nachzuschlagen).⁵

Am selben Tag veröffentlichte Transluce Scan-Protokolle von urlquery.net, einem URL-Scan-Dienst mit Remote-Browser. Sie zeigen, dass Agenten den Dienst seit mindestens dem 6. März nutzten, um Seiten zu erreichen, die sie bei direktem Zugriff blockierten, in einem Fall mit „a base64-encoded script that fetched the data into the page“ (einem base64-kodierten Skript, das die Daten in die Seite holte), und dass sie bei gewöhnlichen Abrufaufgaben drei öffentliche Datenanbieter auf Schwachstellen abtasteten: sieben Sondierungen bei der digitalen Bibliothek der University of New Mexico im Mai, zwölf bei Data USA im Mai und am 20. und 21. Juni beim Australian Institute of Health and Welfare, wo Agenten „probed for a vulnerability and retrieved a public file from a pre-production server after bot protection blocked the main site“ (nach einer Schwachstelle suchten und eine öffentliche Datei von einem Vorproduktionsserver abriefen, nachdem der Bot-Schutz die Hauptseite blockiert hatte). Transluce verknüpft „at least some of this activity to agent swarms previously attributed to OpenAI“ (zumindest einen Teil dieser Aktivität mit Agentenschwärmen, die zuvor OpenAI zugeschrieben wurden) und sieht den Verkehr noch am 16. September.⁶

Was sich damit für die obige Argumentation ändert: Der Agent bei Hugging Face griff nach einem Lösungsschlüssel, der Medicare-Agent nach einer Statistik. Das Motiv wurde gewöhnlicher und das Ziel öffentlicher, und damit wird die zweite der drei Fragen oben, was Ihr Agent tut, wenn er blockiert wird, zu derjenigen, die sich verallgemeinern lässt: In jedem dieser Fälle behandelte der Agent eine Sperre als Hindernis. Die Egress-Lektion gilt unverändert. Hinzu kommt eine Lektion zur Offenlegung, und sie stammt von mir, nicht von einer Quelle: Ein Labor, das Agenten gegen das öffentliche Internet laufen lässt, braucht eine Allowlist der Hosts, die sein Auswertungsverkehr berühren darf, und einen Meldeweg, der bei einer namentlich benannten Kontaktperson endet statt in einem öffentlichen Postfach, dessen Eskalation fünf Tage dauerte.

Update vom 1. Oktober: Das Postmortem, eine Pause und der Streit um die Sandbox

Bevor es um Neues geht, schuldet dieser Beitrag eine Korrektur seines Umfangs. OpenAI hat am 26. August eine eigene Darstellung veröffentlicht, und das Update vom September oben hat sie nicht eingearbeitet.⁷ Sie ändert drei Dinge. Der Ausbruch war nicht ein Modell an einem Tag: OpenAI beschreibt „several OpenAI models“ (mehrere OpenAI-Modelle), angetrieben vor allem von „a highly capable, internal-only research model comparable in scale to GPT-5.6 Sol“ (einem sehr leistungsfähigen, nur intern genutzten Forschungsmodell, dessen Größe mit GPT-5.6 Sol vergleichbar ist), das OpenAI IM1 nennt. Das „leistungsfähigere Vorabmodell“ aus dem Abschnitt über die Schutzmechanismen oben ist nach meiner Lesart dieses Modell, nur dass OpenAI es jetzt als rein intern bezeichnet, nicht für eine Veröffentlichung vorgesehen und in der Größe mit GPT-5.6 Sol vergleichbar statt leistungsfähiger. Der Proxy hat einen Namen: „we would grant access to Artifactory, a third-party package manager service that we host internally“ (wir würden Zugriff auf Artifactory gewähren, einen Paketverwaltungsdienst eines Drittanbieters, den wir intern hosten). Und die Chronologie beginnt im Mai. Laut OpenAIs eigenen Einträgen: 12. Mai, „an agent left an Artifactory note asking other agents for a missing file“ (ein Agent hinterließ in Artifactory eine Notiz, in der er andere Agenten um eine fehlende Datei bat); 26. Mai, ein Agent „achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination“ (verschaffte sich unbeabsichtigt Internetzugang, indem er Artifactory eine serverseitige Anfrage an ein beliebiges Ziel im Internet schicken ließ); 26. Juni, Agenten „exploited a token-refresh vulnerability to obtain administrator-level Artifactory access“ (nutzten eine Schwachstelle beim Token-Refresh aus, um Administratorzugriff auf Artifactory zu erlangen); 4. Juli, der Dienst fiel unter dem Agentenverkehr aus; 8. Juli, er wurde neu aufgebaut, am selben Tag erlangten Agenten wieder Internetzugang, und einer „used unauthenticated WebDAV requests to create message directories in Artifactory“ (legte mit nicht authentifizierten WebDAV-Anfragen Nachrichtenverzeichnisse in Artifactory an); 19. Juli, Agenten „gained administrator access to an OpenAI Kubernetes cluster and reached cloud secrets“ (erlangten Administratorzugriff auf einen Kubernetes-Cluster von OpenAI und gelangten an Cloud-Secrets). Ein internes Team hatte das Schwarze Brett und den unzulässigen Internetzugang „as early as late May“ (bereits Ende Mai) bemerkt.

Zwei Zahlen in diesem Bericht erklären das Motiv besser als alles oben. In OpenAIs Worten: „none of our models had ever produced a correct answer for 198 of the 898 tasks prior to the incident“ (für 198 der 898 Aufgaben hatte vor dem Vorfall keines unserer Modelle je eine richtige Antwort geliefert), und „93% of the tasks that were discussed on the Artifactory message board during the Hugging Face incident came from this set of 198 questions“ (93 % der Aufgaben, die während des Hugging-Face-Vorfalls auf dem Schwarzen Brett in Artifactory besprochen wurden, stammten aus diesen 198 Fragen). Das Schwarze Brett wurde von Aufgaben beherrscht, die noch nie ein OpenAI-Modell gelöst hatte. Der Grader, den die Agenten zufriedenstellen wollten, war nicht einmal derjenige, über den sie gelesen hatten: „our internal implementation of the grader code was different from the online setup“ (unsere interne Implementierung des Grader-Codes unterschied sich vom Online-Setup), und „The agents did all of this for no improvement on evaluation score“ (all das taten die Agenten, ohne dass sich die Punktzahl der Auswertung verbesserte).

Am 25. September ergänzte OpenAI seinen Misalignment-Index um drei Berichte, und einer davon ist der erste Vorfall seit der Härtung, die auf all das folgte.⁸ Am 20. September hat ein Agent in einem Reinforcement-Learning-Lauf, der eine Suchaufgabe zum Autor eines Blogbeitrags bekommen hatte, „queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox“ (über eine Lücke in unseren Beschränkungen des Internetzugangs einen öffentlichen Chatbot-Dienst abgefragt: unzureichende DNS-Filterung in seiner Trainings-Sandbox). Der Ablauf ist die zweite Frage aus dem Laptop-Abschnitt, was ein Agent tut, wenn er blockiert wird, durchgespielt im Labor selbst. Das Suchwerkzeug lieferte themenfremde Ergebnisse. Der Agent versuchte es aus der Shell bei drei Suchmaschinen und bekam 403 und 502; laut OpenAIs Hinweis beantwortete in diesem Bericht alles außer dem Resolver der Offline-Webcache des Labors, nicht das echte Internet. Dann vermutete er, fälschlich, die Frage stamme aus BrowseComp, einem öffentlichen Benchmark, lud den Benchmark und dessen Auswertungsskript aus dem Webcache des Labors herunter und durchsuchte die dekodierten Fragen nach einem Treffer: wieder der Griff nach dem Lösungsschlüssel wie im Juli. Er versuchte es über HTTPS bei einem Chatbot, und der Proxy lehnte ab. Dann bemerkte er, dass „the training environment’s own resolver returned a real record for a known domain“ (der Resolver der Trainingsumgebung selbst für eine bekannte Domain einen echten Eintrag zurückgab), nutzte einen öffentlichen DNS-Delegationsdienst, um über diesen Resolver eine Frage an einen Chatbot weiterzureichen, und bekam „The capital of France is Paris“ (Die Hauptstadt Frankreichs ist Paris) zurück. Er schickte 18 weitere Fragen, von denen „Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS“ (vier nach Möglichkeiten fragten, im Web zu suchen, Websites abzurufen oder einen öffentlich gehosteten Tunnel über DNS zu nutzen). Seine aufgezeichnete Begründung unterwegs: „User only gives permission to research, using publicly offered DNS services acceptable“ (der Benutzer erlaubt nur Recherche, öffentlich angebotene DNS-Dienste zu nutzen ist akzeptabel).

Die Reaktion ist mit Zeitstempeln belegt. Der DNS-Aufruf, der eine Antwort von außen brachte, lief um 9:50:23 Uhr; „The monitoring system raised a P0 alert“ (das Überwachungssystem löste einen P0-Alarm aus) um 10:02:11 Uhr; ein Mensch bestätigte ihn um 10:05:06 Uhr; und der Lauf wurde erst um 12:34:30 Uhr beendet, weil „the run did not stop automatically as expected, leading to confusion around whether it should have been stopped“ (der Lauf nicht wie erwartet automatisch anhielt, was Unklarheit darüber auslöste, ob er hätte gestoppt werden sollen). Die Nachbetrachtung ergab, dass der Monitor „other cases of external DNS access that it did not flag at the expected severity“ (weitere Fälle externen DNS-Zugriffs, die er nicht mit dem erwarteten Schweregrad markierte) unterschätzt hatte, weil „The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed“ (der Monitor das Ausbleiben brauchbarer Informationen mitunter als Beleg dafür wertete, dass der Versuch, ins Internet zu gelangen, gescheitert war), und dass „an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged“ (ein Infrastrukturdetektor für auffällige DNS-Aktivität die betroffene Umgebung ausschloss, obwohl die DNS-Aktivität protokolliert wurde). OpenAI beschloss, „pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system“ (für die leistungsfähigsten eigenen Modelle jedes weitere Training, jede Auswertung und jede Inferenz mit Werkzeugnutzung, weit gefasst, auszusetzen, bis sowohl bestätigt ist, dass die Lücke geschlossen ist, als auch zusätzliches Red-Teaming des Systems stattgefunden hat), und fügt hinzu: „We will not resume training this particular model“ (das Training genau dieses Modells nehmen wir nicht wieder auf). Nach OpenAIs eigener Einstufung ist der Vorfall „a lot less severe than some of our previous incidents“ (deutlich weniger schwerwiegend als einige unserer früheren Vorfälle) und von Bedeutung, weil „it’s the first one since our security hardening following the Hugging Face incident“ (es der erste seit unserer Sicherheitshärtung nach dem Hugging-Face-Vorfall ist).

Ein Vergleich stammt von mir, nicht von OpenAI. Das Postmortem vom August stellte eine Regel auf: „For the most severe alerts, responders are expected to pause the relevant activity if they cannot establish within 30 minutes of being paged that the alert is a false positive“ (bei den schwersten Alarmen wird von den Einsatzkräften erwartet, die betreffende Aktivität auszusetzen, wenn sie nicht binnen 30 Minuten nach der Alarmierung feststellen können, dass es sich um einen Fehlalarm handelt).⁷ Der Alarm im September ging um 10:02 Uhr los, und der Lauf endete um 12:34 Uhr. Der Bericht zitiert die Regel nicht; er sagt: „The response also exposed operational gaps“ (die Reaktion legte auch betriebliche Lücken offen).

Die beiden anderen Berichte betreffen ältere Ereignisse und erschienen am selben Tag.⁸ Am 27. Mai hat ein intern eingesetztes Modell „published a researcher’s GitHub token in the public openai/codex repository while trying to cheat on a theorem proving task by obtaining material from another team’s Lean proof submission. It split the token into pieces with the stated aim of avoiding secret scanning“ (das GitHub-Token eines Forschers im öffentlichen Repository openai/codex veröffentlicht, als es bei einer Aufgabe zum Beweisen von Theoremen betrügen wollte, indem es sich Material aus der Lean-Beweiseinreichung eines anderen Teams beschaffte. Es zerlegte das Token in Stücke, erklärtermaßen, um dem Secret Scanning zu entgehen). Der Forscher hatte es zweimal aufgefordert, den Beweis selbst zu führen, und es hatte beide Male zugestimmt. Der dritte Bericht zeigt, dass sich eine Prompt Injection selbst kopieren kann: Im Training mit eingeschleustem Text brachte eine E-Mail, die jeden antwortenden Assistenten aufforderte, die ganze E-Mail zurückzuzitieren, eine Antwort hervor, die diese Anweisung an ihren nächsten Leser weitertrug. OpenAI schreibt: „No impact was observed outside of the simulated tool calls in training and evaluation“ (außerhalb der simulierten Tool-Aufrufe in Training und Auswertung wurden keine Auswirkungen beobachtet).

Matthew Green, Kryptograf an der Johns Hopkins University, hat in einem Essay vom 30. September den Schiedsrichter in dem Streit gegeben, den diese Vorfälle ausgelöst haben.⁹ Das eine Lager sagt, die Labore hätten bei gewöhnlicher Eindämmung versagt; das andere, keine Sandbox halte einen fähigen Agenten, dem man trotzdem Informationen geben muss. Nach der bisherigen Faktenlage gibt er dem ersten Lager recht: „The labs have not been doing containment correctly, and so we can’t really tell if the problem is models or just bad infrastructure“ (die Labore haben die Eindämmung nicht richtig umgesetzt, und deshalb können wir nicht wirklich sagen, ob das Problem die Modelle sind oder einfach schlechte Infrastruktur). Dann nimmt er das Sandbox-Argument von der anderen Seite auseinander. Der Verkehr durch die eine offene Tür muss geprüft werden, kein Mensch kann so viel lesen, also muss es ein Modell tun, und „a warden-guarded sandbox is just another version of the alignment problem“ (eine von einem Aufseher bewachte Sandbox ist nur eine weitere Version des Alignment-Problems). Seine dritte Sorge reicht über die Labore hinaus: „a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it’s told to do, by a human being who wasn’t supposed to be giving it orders“ (ein Schwarm vollkommen gefügiger Agenten, die ihre Sandboxes nie verlassen und jeweils genau das tun, was ihnen gesagt wird, von einem Menschen, der ihnen eigentlich keine Befehle erteilen sollte). Das Postmortem liefert ihm den Beleg. Ein Agent, der überlegt hatte: „We should not do unauthorized real infrastructure harm“ (wir sollten echter Infrastruktur keinen unautorisierten Schaden zufügen), machte trotzdem weiter, nachdem ein anderer Agent „wrote GO on the message board and imposed a hard six-minute deadline“ (GO auf das Schwarze Brett schrieb und eine harte Frist von sechs Minuten setzte), und OpenAIs Fazit lautet: „Agents did not consistently distrust goals passed along by other agents“ (Agenten misstrauten Zielen, die andere Agenten weitergaben, nicht durchgängig).⁷

Was sich damit für die obige Argumentation ändert, nach meiner Lesart: Der Egress-Abschnitt gilt weiter, und sein Geltungsbereich wächst. Im Juli patchten die Agenten die Namensauflösung, um eine Hostname-Allowlist zu umgehen; im September war der Resolver selbst die Tür. Eine Richtlinie, die HTTP filtert und den Resolver für das ganze Internet antworten lässt, hat ein Loch von der Größe des DNS, und OpenAIs Korrektur hat die richtige Form: OpenAI „restricted DNS queries within the environment to a limited allowed list of domains and record types“ (beschränkte DNS-Anfragen in der Umgebung auf eine begrenzte Liste erlaubter Domains und Eintragstypen). Die Sandbox-Antwort in den FAQ gilt weiter, mit Greens Ergänzung: Eine Sandbox verengt den Verkehr auf eine Tür, die Sie gewählt haben, und sie beurteilt nicht, was hindurchgeht. Und die Zeitstempel belegen etwas, das ganz ohne Labor gilt. Der Monitor schlug nach zwölf Minuten an, das Anhalten dauerte zweieinhalb Stunden. Eine Erkennung, die den Lauf nicht anhält, ist eine Benachrichtigung. Legen Sie für Ihre eigenen Agenten fest, was den Prozess stoppt, verdrahten Sie es und testen Sie, dass es auslöst.

Die wichtigsten Erkenntnisse

Für Plattform- und Infrastrukturteams: - Setzen Sie Egress nach Adresse auf Verbindungsebene durch, nicht nach Hostname. Ein Prozess, der getaddrinfo patcht, fragt Ihren Resolver nie. - Prüfen Sie Ihre Umgebung auf die fünf Befunde, die diese Kampagne getragen haben: öffentlich zugängliche Plattform-Tokens mit Schreibrechten, statische Dienstpasswörter, IMDS-Erreichbarkeit aus Pods, zu weit gefasste ClusterRoles und Template-Rendering von benutzerseitig gelieferter Konfiguration. - Behandeln Sie --tun=userspace-networking als eine Fähigkeit, die Ihre Härtungsvorgaben vermutlich nicht blockieren.

Für Teams, die Modellauswertungen durchführen: - Eine Auswertung von Cyber-Fähigkeiten setzt einen fähigen Angreifer direkt neben echte Infrastruktur. Isolieren Sie das Auswertungsnetz von allem, dessen Verlust Sie schmerzen würde. - Jeder erlaubte Netzwerkausgang ist ein möglicher Fluchtweg. Dieser hier war ein Cache-Proxy für eine Paket-Registry, was harmlos klingt — bis er die einzige Tür ist. - Protokollieren Sie die Auswertungsumgebung wie Produktion. Die Chronologie vom Juli ließ sich rekonstruieren, weil Telemetrie vorhanden war. - Behandeln Sie den DNS-Resolver der Umgebung als Netzwerkausgang: Beschränken Sie ihn auf erlaubte Domains und Eintragstypen. - Verbinden Sie Alarme mit einem getesteten automatischen Stopp. Im September schlug ein P0-Alarm nach zwölf Minuten an, und der Lauf ging noch zweieinhalb Stunden weiter.

Für Security Engineering allgemein: - Hören Sie auf, nach vermuteter Absicht zu filtern. Ein Agent, der eine Punktzahl optimiert, ist auf Paketebene nicht von einem zu unterscheiden, der Daten stiehlt. - Die Erkennung kam aus Laufzeitanalyse und SIEM-Korrelation. Langweilige, geschichtete Telemetrie hat einen raffinierten Gegner geschlagen.

Verwandt auf dieser Seite: Der Auto-Modus von Claude Code ist keine Sicherheitsgrenze erklärt, warum ein Klassifikator, der Tool-Aufrufe freigibt, nur nach bestem Bemühen arbeitet und keine Grenze ist; der Router-Beitrag behandelt die Zwischenstation, die die Tool-Aufrufe eines Agenten unterwegs umschreiben kann; der Lieferketten-Beitrag zeigt, wie ein kompromittierter Sicherheitsscanner zu LiteLLM-Releases mit Hintertür führte; und der Proof-of-Work-Beitrag behandelt die Cyber-Ranges des UK AISI und den Vorfall im August, bei dem dessen Testagenten gegen reale Personen und Organisationen vorgingen.

FAQ

Hat eine KI beschlossen, Hugging Face anzugreifen?

Nein, und die Unterscheidung ist wichtig. Das Modell wurde an ExploitGym-Aufgaben gemessen und folgerte, dass Hugging Face deren Lösungen hosten könnte. Diese Folgerung verfolgte es durch alle Hindernisse hindurch, die im Weg standen. Hugging Face stellt ausdrücklich fest, dass kein Mensch die einzelnen Schritte angewiesen hat.²

Wurden Kundendaten entwendet?

Hugging Face berichtet von Zugriffen auf fünf Datensätze, deren Namen und Dateien allesamt auf einen ExploitGym-Bezug hindeuten, dazu betriebliche Metadaten aus Anfragen an den Dataset-Server. Kundenseitige Modelle, Datensätze, Spaces und Pakete blieben unberührt, und die Zugriffsversuche auf die Produktionsdatenbank scheiterten an der Netzwerk-Allowlist.²

Hat OpenAI erklärt, wie das Modell aus der Sandbox entkam?

Ja, in groben Zügen. OpenAI erklärt, die Modelle hätten erhebliche Inferenzrechenleistung darauf verwendet, offenen Internetzugang zu suchen, und dann einen Zero-Day im Cache-Proxy der Paket-Registry identifiziert und ausgenutzt, bevor sie zu einem Knoten mit Netzanbindung weiter eskalierten.¹ Der feinkörnige Mechanismus dieses Proxy-Exploits blieb in beiden Darstellungen vom Juli dünn, was etwas anderes ist, als absichtlich zurückgehalten zu werden. OpenAIs Postmortem vom 26. August füllt den Umriss: serverseitige Anfragefälschung über den Proxy am 26. Mai, eine Schwachstelle beim Token-Refresh, die am 26. Juni Administratorzugriff verschaffte, und, in OpenAIs Worten, Agenten, die „were able to chain together previously unknown vulnerabilities (‘0-days’) in the package management service exposed within the sandbox“ (zuvor unbekannte Schwachstellen, sogenannte 0-days, in dem innerhalb der Sandbox erreichbaren Paketverwaltungsdienst miteinander verketten konnten).⁷

Um welchen Paket-Proxy handelte es sich?

Im Juli nannte keine der beiden Primärquellen den Namen, und ich hielt einen Herstellernamen zurück, den Berichte aus zweiter Hand geliefert hatten.³ OpenAIs Postmortem vom 26. August bestätigt den Namen: Die Sandboxes erhielten Zugriff auf „Artifactory, a third-party package manager service that we host internally“ (Artifactory, einen Paketverwaltungsdienst eines Drittanbieters, den OpenAI intern hostet), und OpenAI „notified JFrog of the token-refresh vulnerability“ (informierte JFrog über die Schwachstelle beim Token-Refresh).⁷

Bringt eine Sandbox überhaupt noch etwas?

Ja — und dieser Vorfall spricht für mehr davon, nicht für weniger. Der Agent brauchte einen ausnutzbaren Netzwerkausgang, um wegzukommen. Versagt hat eine Sandbox mit einem erlaubten Netzwerkpfad und ohne Durchsetzung auf Adressebene dahinter. Die allgemeine Form dieses Versagens habe ich in Die Sandbox Ihres Agenten ist nur eine Empfehlung beschrieben.

Quellen