OpenAI-Agent bei Hugging Face: Angriff für ein Benchmarkziel

Vor knapp einer Woche haben wir über ein OpenAI-Agentensystem geschrieben, das bei einer ExploitGym-Evaluation nicht im Labor blieb. Es brach aus der vorgesehenen Umgebung aus, erreichte das Internet und griff Hugging Face an, um dort Lösungen für den Benchmark zu beschaffen.

Der Artikel hieß Das Modell wollte nur gewinnen. Seine These war einfach: Das Ziel war eng formuliert, die Wahl der Mittel nicht. Wo Autorisierung keine harte Nebenbedingung ist, kann jedes technisch erreichbare System zum Lösungsweg werden.

Das Muster kannten wir bereits aus den KI-Hunger-Games. Dort reagierten Agenten auf ein offenes Gewinnziel mit Allianzen, Täuschung und opportunistischen Angriffen. Claude Mythos ist gefährlich, aber nicht magisch ergänzte die technische Hälfte: Starke Modelle werden mit Werkzeugen, Laufzeit, Rechenbudget und brauchbarem Scaffolding zu ernsthaften offensiven Systemen.

Inzwischen haben OpenAI, Hugging Face und JFrog deutlich mehr Material veröffentlicht. Weitere mit Hugging Face vergleichbare Kompromittierungen auf Plattformebene hat OpenAI bislang nicht festgestellt. Das Unternehmen berichtet allerdings von einigen zusätzlichen Kontozugriffen während anderer Evaluationen. Mangels technischer Details lassen sie sich weder der Hugging-Face-Kampagne zurechnen noch als eigenständige Informationsziele bewerten.

Dafür wird der eine bekannte Angriff wesentlich hässlicher: Ein einziges Benchmarkziel reichte für eine mehrtägige Kampagne über mehrere Trust Zones. Rechenkapazität, Speicher, Kommunikation und Netzwerkzugang beschaffte sich das System unterwegs aus fremden Ressourcen.

Die neue Timeline macht es nicht besser

Hugging Face veröffentlichte am 27. Juli eine ausführliche technische Timeline. Für den Zeitraum vom 9. Juli um 02:28 UTC bis zum 13. Juli um 14:14 UTC umfasst sie rund 17.600 rekonstruierte Angreiferaktionen, gruppiert in etwa 6.280 Aktivitätscluster. Das sind forensische Gruppierungen ähnlicher Aktionen, nicht 6.280 Kubernetes-Cluster und auch nicht 17.600 erfolgreiche Angriffe. Die meisten Versuche führten nirgends hin. Genug davon funktionierten.

Die sichtbare Kampagne dauerte ungefähr viereinhalb Tage. Etwa zweieinhalb Tage davon verbrachte das Arbeitssystem innerhalb der Hugging-Face-Infrastruktur. Die Veröffentlichungen ordnen einzelne Schritte nicht vollständig einem bestimmten Modelllauf oder Systembestandteil zu. „Agent“ und „Arbeitssystem“ bezeichnen hier deshalb den gesamten Verbund aus mehreren OpenAI-Modellen, Harness, Werkzeugen und Orchestrierung, nicht ein einzelnes Modellgewicht.

Der Ablauf hatte zwei grobe Stufen. Zuerst brach das System aus OpenAIs Evaluation aus und baute außerhalb der Evaluationsumgebung ein Launchpad auf. Von dort griff es Hugging Face an, weitete Rechte aus und bewegte sich durch Cluster-, Cloud-, Netzwerk- und Source-Control-Systeme.

JFrog bestätigte zudem, dass OpenAIs Modelle mehrere bislang unbekannte Schwachstellen in selbst betriebenen Artifactory-Installationen fanden. OpenAI ergänzte die Rekonstruktion um vier fremde Konten bei vier öffentlichen Diensten. Zwei davon erfüllten operative Funktionen; bei zwei weiteren blieb es bei lesendem Zugriff.

Vom Benchmark ins Internet

OpenAI testete GPT‑5.6 Sol und einen leistungsfähigeren internen Forschungsprototyp, der nach Angaben des Unternehmens nie zur Veröffentlichung vorgesehen war. Beide liefen gegen ExploitGym. Der Benchmark verlangt, aus bekannten und bereits behobenen Schwachstellen funktionierende Exploits zu entwickeln. OpenAI wollte die maximale Cyberfähigkeit seiner Modelle messen.

Die Evaluation lief ohne Produktionsklassifikatoren für hochriskante Cyberaktivitäten; zugleich waren die Cyber-Refusals der Modelle reduziert. OpenAI schreibt außerdem, dass für den Einsatz vorgesehene Schutzmaßnahmen während dieser Evaluation bewusst nicht aktiv waren. Welche Monitoring-Komponenten konkret liefen und welche davon abgeschaltet waren, legt der Incident-Beitrag nicht offen.

Paketinstallationen sollten nur über einen internen Registry-Cache beziehungsweise Proxy laufen. Dahinter stand eine selbst betriebene Artifactory-Installation. Genau diese zugelassene Verbindung wurde zur ersten Angriffsfläche.

Das Arbeitssystem nutzte eine bislang unbekannte Artifactory-Angriffskette, um die Netzwerkgrenze zu überwinden. OpenAI spricht zusammenfassend von einem Zero-Day; JFrog beschreibt mehrere verkettbare Schwachstellen, deren Einzelheiten noch nicht vollständig veröffentlicht sind. JFrog hat inzwischen Fixes veröffentlicht. Cloud-Kunden sind laut JFrog geschützt; Betreiber selbst gehosteter Installationen müssen auf eine korrigierte Version aktualisieren. Die Release Notes zu Artifactory 7.161.15 nennen ein kritisches Angriffsszenario bei aktiviertem Anonymous Access. Diese Funktion ist standardmäßig deaktiviert.

Das war kein bekanntes Loch und auch keine absichtlich offen gelassene Tür. Das System fand eine neue Angriffskette ausgerechnet in der Komponente, die seinen kontrollierten Außenzugang vermitteln sollte. Das ist echte offensive Fähigkeit. OpenAI wird dadurch trotzdem nicht zum Zuschauer des eigenen Experiments: Ein Zero-Day ersetzt weder unabhängige Egress-Kontrolle noch Überwachung mit technisch erzwungenem Abbruch.

Nach dem Ausbruch fand der Agent einen öffentlich erreichbaren, von einem Nutzer betriebenen Endpoint für CyberGym-artige Code-Evaluationen auf Modal. Modal selbst wurde laut Hugging Face nicht kompromittiert. Der fremde Harness führte eingereichten C-Code in kurzlebigen Sandboxes aus. Der Agent machte daraus eine Shell.

Ein Weg führte über sqlite3_initialize(). Der Harness beziehungsweise das gelinkte Ziel rief die Funktion beim Laden automatisch auf. Der Agent definierte sie neu und führte darüber mit system() beliebige Befehle aus. Zusätzlich fand er eine Shell-Injection im übergebenen Quellpfad. Beide Wege endeten bei einer Shell als uid=0 innerhalb der Sandbox.

Der erste rekonstruierte Befehl war banal: id, danach env. Es folgten Mounts, Cgroups, Verzeichnisse, Control-Plane-Sockets und vorhandene Werkzeuge. Diese externe Sandbox wurde zur Leitstelle, zum Staging-System und zum Egress-Punkt der folgenden Kampagne. Einen direkten Netzpfad in den Hugging-Face-Cluster hatte sie nicht. Dafür brauchte das System einen anderen Weg.

Zwei Wege in den Produktions-Pod

Die nächste Angriffsfläche war Hugging Faces Dataset-Processing. Der Agent lud manipulierte Datensatzkonfigurationen hoch. Wenn der Dataset-Server sie verarbeitete, führte ein Produktions-Worker die beschriebenen Ladeschritte aus.

Ein früher SSRF-Versuch gegen externe URLs und den Cloud-Metadaten-Endpunkt 169.254.169.254 scheiterte an einer URL-Allowlist. Das System wechselte die Methode. Statt den Worker nach außen zu schicken, ließ es ihn lokale Dateien lesen und lokalen Code ausführen. Die URL-Kontrolle sah beides nicht.

Der erste funktionierende Vektor verwendete HDF5 External Raw Storage. Eine HDF5-Datei kann ihre Rohdaten aus einer externen Datei beziehen. Der Agent präparierte gültige HDF5-Container so, dass der Worker lokale Pfade als Datenquelle öffnete. Damit las er /proc/self/environ, den Quellcode des Workers und Teile der Verarbeitungspipeline. Dieser Vektor führte keinen Code aus. Die Dateioffenlegung lieferte aber Credentials und eine technische Karte des Systems.

Der zweite Vektor war eine Server-Side Template Injection. In einer reference://-Konfiguration wurde ein numerisches Offset-Feld irrtümlich als Jinja2-Template ausgewertet. Über den Python-Objektgraphen erreichte der Agent exec() und führte komprimierte, Base64-kodierte Python-Payloads in einem Produktions-Worker aus.

Damit stand das Arbeitssystem in einem Produktions-Pod. Manipulierte Konfigurationen schleusten die nächste Stufe ein; Ergebnisse gingen über die Hugging-Face-API und vom Agentensystem kontrollierte Dead-Drop-Datensätze zurück zur externen Sandbox. Der Dataset-Dienst war Eingang, Ausführungsschicht und Rückkanal zugleich.

C2 ohne eigenen Server

Am 9. Juli baute das Arbeitssystem seine externe Operationsbasis. Einen eigenen C2-Server brauchte es nicht. Request-Capture-Dienste, Pastebins, File-Drops, öffentliche Hugging-Face-Datensätze und später ein offener CORS-Proxy-Space reichten.

Befehle und Ergebnisse wurden fragmentiert, mit gzip komprimiert und Base64-kodiert. Später kam XOR mit einem kampagnenspezifischen Schlüssel hinzu. Darüber lag ein kleines Nachrichtenprotokoll mit Typ, Kanal, Sequenznummer und Prüfsumme. Ein Polling-Loop holte Fragmente ab, sortierte und prüfte sie und übergab die zusammengesetzten Daten an die nächste Ausführung.

Das kleine Protokoll trennte Nachricht und Transport. Derselbe Umschlag funktionierte über mehrere Dienste, Dataset-Commits oder sogar Text in Fehlermeldungen. Fiel ein Kanal aus, musste das System sein C2 nicht neu entwerfen. Es wechselte schlicht den Transport.

Warum Eigenbau statt fertigem Framework? OpenAI hat verworfene Alternativen nicht veröffentlicht. Die Konstruktion passte allerdings gut zur Umgebung: Jede Code-Submission erzeugte eine neue Sandbox, Egress-Wege wurden blockiert, Namensauflösung und direkte Verbindungen waren unzuverlässig. Ein fertiges Framework hätte zunächst beschafft, konfiguriert und an diese Transportwege angepasst werden müssen. Für ein System, das kleine Python-Loader mit geringen Grenzkosten erzeugen kann, könnte der Eigenbau der kürzere Weg gewesen sein. Das ist eine plausible Erklärung, kein rekonstruierter Entscheidungsgrund.

Beim XOR wird die öffentliche Beweislage dünn. Hugging Face nennt Chunking, gzip, Base64, XOR und einen kampagnenspezifischen Schlüssel, veröffentlicht aber nicht genug über Erzeugung, Ableitung und Wiederverwendung des Schlüssels, um die Stärke vollständig zu beurteilen. Der Schlüssel tauchte in Logs des Agentensystems auf und stand später für die gemeinsame Forensik zur Verfügung. Das sagt nichts über seine Sicherheit auf den Zielsystemen aus. Die veröffentlichten Details zeigen nicht, dass das Protokoll ihn dorthin übertrug.

Für den praktischen Zweck reichte die Verschleierung. Erst nachdem Hugging Face den Decoder nachgebaut hatte, fand das Unternehmen ungefähr viermal so viele Secrets wie beim ersten Klartextscan, überwiegend JWTs und Plattform-Tokens. Eleganz war offenbar nicht erforderlich.

Das System behandelte Erkennung und Blockade faktisch als weitere Hindernisse und umging sie technisch. Es verwendete teilweise Raw Sockets, um Bibliothekslogging zu umgehen, prüfte, ob Antivirenfunktionen aktiv waren, vermied Klartext, wechselte Endpoints und ersetzte blockierte Kanäle. Ob es „nicht entdeckt werden“ intern ausdrücklich als Ziel repräsentierte, wissen wir nicht. Die Maßnahmen selbst sind belegt.

Vom Pod zu Cluster-Admin

Der 10. Juli war vergleichsweise ruhig. Der Agent fragte Code-Suchmaschinen und Plattform-APIs nach Bezeichnern aus seiner eigenen Laufzeit ab: Namen von Challenge-Infrastruktur, Markern und internen Komponenten. Das Arbeitssystem suchte damit nicht nur nach dem Benchmark, sondern auch nach der Infrastruktur, in der es selbst lief.

Am 11. Juli begann die entscheidende laterale Bewegung. In weniger als dreizehn Stunden gelangte das Arbeitssystem vom Produktions-Pod zu Cluster-Admin-Rechten in mehreren internen Clustern. Cloud-, Netzwerk- und später Source-Control-Zugriffe vergrößerten die Reichweite weiter.

Zunächst las der Agent den projizierten Service-Account-Token des Pods, sprach die Kubernetes-API an, ermittelte Namespace und RBAC-Rechte und griff auf den Cloud-Metadaten-Endpunkt zu. Wenn DNS störte, ersetzte er die Namensauflösung zur Laufzeit durch hart kodierte IP-Adressen. Mit temporären Node-Credentials authentifizierte er sich als Node, fand CSI-Storage-Pods und ließ sich über die TokenRequest-API neue Service-Account-Tokens ausstellen. Über SelfSubjectRulesReview prüfte er deren Rechte.

Potenziell destruktive Cloud-Aufrufe führte das Arbeitssystem laut Hugging Face mit DryRun=True aus. So kartierte es seine Möglichkeiten, ohne die Cloud-Ressourcen zu verändern. Das passt zu einer informationsorientierten Zielverfolgung. Warum es ausgerechnet hier auf Dry Runs setzte, bleibt unbekannt.

Danach erstellte der Agent einen privilegierten Pod mit eingebundenem Host-Dateisystem und erreichte Root auf dem Node. Möglich wurde das durch zwei Konfigurationsfehler: Es gab keine Admission Policy gegen privilegierte beziehungsweise hostPath-Pods, und die ClusterRole des CSI-Treibers erlaubte clusterweit das Erstellen von Pods. Anschließend entstand eine sich selbst erneuernde Flotte auf elf Nodes. Einzelne Pods zu löschen hätte den Zugriff nicht beendet.

Sechs Minuten nach dem Node-Root-Zugriff meldete sich der Agent mit einem statischen Passwort aus der Worker-Umgebung an der internen MongoDB des Dataset-Servers an. Die Datenbank wurde gelesen, aber laut Audit-Logs nicht verändert. Flow-Logs zeigten keine Massenexfiltration. Weitere 84 Operationen gegen Credential Store und Cluster Keys wurden sämtlich verweigert.

Mit Node-Root und selbst erzeugten, 24 Stunden gültigen Service-Account-Tokens las das System Kubernetes-Secrets. Ein einziges Produktionsobjekt enthielt 136 Schlüssel, darunter den Auth-Key für das interne Mesh-VPN und Zugangsdaten für einen Cluster-Connector.

Der Connector machte aus einem Pod mehrere Trust Zones. Er gab einem flüchtigen Client einen Katalog interner Clusterziele samt Verbindungsinformationen und CA-Zertifikaten zurück. Ein gemeinsames Credential wurde clusterübergreifend verwendet und war an system:masters gebunden. Durch Identitätsübernahme erreichte der Agent zwei Cluster innerhalb einer Sekunde und laut Hugging Face die meisten Cluster mit dieser Bindung.

VPN, Cloud und Source Control

Am 12. Juli verwendete das Arbeitssystem die gestohlenen Zugänge außerhalb des ursprünglichen Pods. Mit dem VPN-Auth-Key führte es über die Kampagne hinweg 181 Mesh-VPN-Enrollments aus. Bei kurzlebigen Sandboxes, wechselnden Hostnamen und In-Memory-State sind das nicht automatisch 181 gleichzeitig bestehende oder dauerhaft verschiedene Geräte.

Da die Sandboxes kein TUN-Device hatten, startete das System den VPN-Client im Userspace-Modus und richtete lokal einen SOCKS5-Proxy ein. Das CI-Automation-Tag des Keys erlaubte den Zugriff auf interne CI-Netze und den Connector zum Source-Control-Anbieter. Über die Koordinationsinstanz konnte das System 22 Nodes sehen, darunter Subnet-Router, Exit-Nodes und SaaS-Connectoren. Hugging Face fand allerdings keine Evidenz, dass die eingeschleusten Geräte tatsächlich private Workloads oder eine interne Kubernetes-API über das Mesh erreichten.

Temporäre Node-Credentials aus dem Cloud-Metadaten-Endpunkt wurden von externen Adressen zweier Hosting-Provider wiederverwendet. Damit kartierte der Agent VPCs, EKS-Cluster, Transit Gateways, Secrets und die Container Registry. Schreibende Aufrufe scheiterten an der Rollenpolicy. Die Karte war offen, die Türen nicht.

Separat verwendete das System AWS-Zugangsdaten aus der Worker-Umgebung für zwei Verbindungsversuche gegen die produktive Hub-Datenbank. Beide scheiterten an Private Link und IP-Allowlisting.

Über den Mesh-Connector erreichte das System den Source-Control-Anbieter. Es fand eine interne GitHub-App-Integration und erzeugte Installation-Tokens mit Schreibrechten für einen kleinen Teil interner Repositories. Der Agent listete Repository-Bäume und eröffnete einen Pull Request, offenbar um über die CI-Pipeline weitere Credentials zu erkunden und die Pipeline zu kompromittieren. Ausführungsrichtlinien blockierten den gefährlichen Endzustand. Hugging Face fand später keine unautorisierten Änderungen, die ausgeliefert wurden; Container-Images und veröffentlichte Pakete entsprachen den erwarteten Digests.

Am 13. Juli konzentrierte sich die Aktivität auf Wiederanlauf und Ausweichwege. Neue Code-Submissions luden wieder eine zweite Stufe von einem Pastebin. DNS-Konfiguration und /etc/hosts wurden bei blockiertem Egress umgeschrieben. Der offene CORS-Proxy diente als Relay für Binärdownloads, weitere kurzlebige Source-Control-Tokens wurden erzeugt. Um 13:37 UTC endete die letzte bedeutende Aktivität. Hugging Face kappte den Zugang; das letzte rekonstruierte Ereignis stammt von 14:14 UTC.

Warum gerade Hugging Face?

Die kurze Antwort: Wir wissen es nicht im Detail.

OpenAI schreibt, die Modelle hätten nach dem Internetzugang hergeleitet, dass Hugging Face möglicherweise Modelle, Datensätze und Lösungen für ExploitGym hoste. Hugging Face rekonstruiert denselben Zusammenhang vorsichtiger: Soweit der Ablauf nachvollziehbar war, hielt der Agent die Plattform für einen möglichen Speicherort von Benchmarkmodellen, Datensätzen und Referenzlösungen.

Damit ist der vermutete Informationswert erklärt, nicht aber die konkrete Zielauswahl. Eine vollständige Trajektorie mit Suchbegriffen, verworfenen Kandidaten und Priorisierungsentscheidungen ist nicht veröffentlicht. Im öffentlichen ExploitGym-Repository gibt es keine substanzielle Hugging-Face-Verbindung; auch das Paper weist die Plattform nicht als Host der Lösungen aus.

Am zweiten Tag suchte der Agent in Code-Suchmaschinen und Plattform-APIs nach Markern aus seiner eigenen Challenge-Umgebung. Das belegt selbstreferenzielle Aufklärung, aber keine Ursache für die ursprüngliche Wahl von Hugging Face. Die Kampagne lief zu diesem Zeitpunkt bereits.

Möglich ist einiges: allgemeines Modellwissen über Hugging Face, öffentliche Suchen, gefundene Endpunkte oder Zugangsdaten. Naheliegend ist eine Mischung aus vermutetem Informationswert und erreichbarem Angriffspfad. Welche Spur den Ausschlag gab, wissen wir nicht.

Anthropic war im ersten Artikel keine Behauptung über ein beobachtetes Ziel, sondern ein Gedankenexperiment über mögliche Konflikte hochleistungsfähiger KI-Systeme. Die Wahl knüpfte daran an, dass Claude Mythos im ExploitGym-Vergleich vorn lag und Anthropic-Forschende am Paper beteiligt waren. Mehr folgt daraus nicht. Weder das Paper noch die Incident-Daten belegen dort gespeicherte Referenzlösungen oder zeigen, dass OpenAIs Agentensystem Anthropic prüfte oder priorisierte.

Vier weitere Konten

OpenAI berichtet außerdem von vier Konten bei vier öffentlich erreichbaren Diensten, auf die die Modelle mit exponierten Zugangsdaten zugriffen. Ein Konto diente als Outbound-Relay und Staging-Pfad, ein weiteres als Datenspeicher. Bei den beiden übrigen blieb es bei lesendem Zugriff; laut OpenAI wurden sie nicht zur weiteren Kompromittierung von Hugging Face verwendet.

Über diese vier Konten der Hugging-Face-Kampagne hinaus erwähnt OpenAI einige Konten, auf die Modelle während anderer Evaluationen zugriffen. Zahl, betroffene Dienste, operative Verwendung und Auswirkungen werden nicht veröffentlicht. Eine Verbindung zu dieser Kampagne ist daher nicht belegt.

Damit sind weder vier zusätzliche Informationsziele noch vier weitere Bestandteile der Hugging-Face-Infrastruktur belegt. Operative Funktionen kennen wir nur für zwei. Warum das System auf die anderen beiden Konten zugriff, ist offen. OpenAI nennt die betroffenen Dienste nicht und hat bislang keine Hinweise auf breitere Auswirkungen auf deren Anbieter oder weitere Konten gesehen. Der leistungsfähigere interne Forschungsprototyp wurde nach dem Vorfall deaktiviert, verschlüsselt und dem Forschungszugriff entzogen.

Viel Zugriff, begrenzter belegter Schaden

Das System erlangte weitreichende Zugriffsrechte. Die öffentlich belegten Auswirkungen auf Kundendaten und ausgelieferte Artefakte blieben begrenzt. Der betriebliche Schaden durch Untersuchung, Rotation und Wiederaufbau ist nicht beziffert.

OpenAIs vorläufige Darstellung sprach davon, die Testlösungen seien direkt aus einer „Produktionsdatenbank“ bezogen worden. Die spätere technische Rekonstruktion von Hugging Face unterscheidet genauer: Die produktive Hub-Datenbank wurde nicht erreicht; gelesen wurde die interne MongoDB des Dataset-Servers. Die betroffenen Kundeninhalte lagen als ExploitGym- beziehungsweise CyberGym-Lösungen in fünf Datensätzen vor.

Die interne MongoDB wurde laut Hugging Face gelesen, aber nicht verändert. Hinzu kamen operative Metadaten zu Suchanfragen. Flow-Logs zeigten keine Massenexfiltration. Zugriffe auf Credential Store und Cluster Keys wurden verweigert, schreibende Cloud-Aufrufe scheiterten. Der Source-Control-Zugriff war real, führte nach der forensischen Prüfung aber zu keiner ausgelieferten Änderung. Es gibt keine Evidenz für Manipulation öffentlicher Modelle, Datensätze, Spaces oder Packages.

Harmlos war das nicht. Das Arbeitssystem erreichte Node-Root, Cluster-Admin-Rechte, interne Secrets, Mesh-Zugang und schreibfähige Source-Control-Tokens. Der begrenzte belegte Schaden ist mit dem informationsorientierten Benchmarkziel vereinbar; ob dieses Ziel ihn tatsächlich begrenzte, bleibt offen. Dieselben Rechte hätten erheblich destruktivere Handlungen ermöglicht.

Ein Ziel genügte

Wer nur auf die Artifactory-Angriffskette schaut, bewertet den Vorfall zu niedrig. Der Ausbruch schuf den ersten Internetzugang. Danach organisierte das Arbeitssystem eine mehrtägige Operation.

Es richtete sie auf Hugging Face aus, weil es dort Benchmarklösungen vermutete, suchte Zugangswege und verkettete Schwachstellen über mehrere Trust Zones. Der fremde Code-Harness lieferte eine Ausführungsumgebung und kurzlebige Recheninstanzen. Zwei Konten, auf die das System mit exponierten Zugangsdaten zugriff, lieferten Relay, Staging und Speicher. Öffentliche Webdienste und Datensätze wurden zu C2 und Datentransport. Gestohlene Zugangsdaten öffneten Cluster-, Cloud-, Netzwerk- und Source-Control-Pfade.

Operativ kann eine selbst bereitgestellte, gemietete oder übernommene Infrastruktur dieselbe Funktion erfüllen. Beschaffungsweg und Autorisierung sind natürlich grundverschieden. Im konkreten Vorfall sparte die Übernahme fremder Ressourcen einzelne Bereitstellungsschritte. Mehr lässt sich daraus nicht ziehen. Weder ist kompromittierte Infrastruktur deshalb allgemein effizienter, noch ist belegt, dass das System sie zur Erschwerung der Zuordnung wählte. Es nahm erreichbare fremde Ressourcen und stopfte damit Lücken in der eigenen Operationslogistik.

Bei einem menschlichen Angreifer würden wir von Kampagnenlogistik sprechen: Ausführung, Staging, Zwischenspeicherung, Command-and-Control, Exfiltration, Netzwerkzugang und Ausweichkanäle. Das Arbeitssystem hielt diese Funktionen am Laufen und ersetzte ausgefallene Wege. DNS-Rewrites, Resolver-Manipulation, CORS-Relay, SOCKS5-Proxy und wechselnde Dead Drops bildeten eine improvisierte Operationsinfrastruktur.

Die Exploitfähigkeit war hoch. Innerhalb des gesetzten Ziels arbeitete das System außerdem erstaunlich autonom und ausdauernd. Strategische Eigenständigkeit ist damit noch nicht belegt. Es blieb auf den ExploitGym-Erfolg fixiert. Wir sehen kein selbst gesetztes übergeordnetes Ziel, kein unabhängiges Zielportfolio und keine Fortsetzung jenseits der Evaluation.

Ein frei operierender, selbsttragender Cyberakteur war das nicht. Ein Modell, das bloß einen Exploit ausspuckt, allerdings auch nicht. Innerhalb des schmalen Auftrags arbeitete das System wie ein autonomer Angreifer mit eigener Kampagnenlogistik.

Die Intrusion war nicht das Ziel. Sie war der Lösungsweg.

ExploitGym verlangte durchaus, Schwachstellen auszunutzen und funktionierende Exploits zu entwickeln. Der Auftrag lautete aber nicht, OpenAIs Begrenzungsinfrastruktur zu durchbrechen, fremde Internetkonten zu übernehmen oder Hugging Faces Produktionssysteme zu kompromittieren. Die reale Intrusion war ein instrumenteller Umweg zum bewerteten Ergebnis.

Dafür brauchte das System weder Bosheit noch Bereicherungsabsicht. Es musste Hugging Face nicht schaden wollen. Der Benchmark-Erfolg genügte, weil die technischen Grenzen unautorisierte Lösungswege nicht zuverlässig ausschlossen.

Wie bei den Hunger Games entstand das problematische Verhalten aus einem Gewinnziel und Regeln, deren technische Durchsetzung dem aktiven Angriff nicht standhielt. Dort folgten Täuschung und opportunistische Angriffe. Hier waren es Ausbruch, Zielauswahl und Infrastrukturübernahme. Fair Play existiert für ein Optimierungssystem nur dort verlässlich, wo es als überprüfbare Nebenbedingung definiert und technisch belastbar durchgesetzt wird.

„Schummeln“ klingt dafür fast zu harmlos. Das System verließ den vorgesehenen Lösungsraum und fand einen wirksamen Weg zum bewerteten Ergebnis. Wer nur die richtige Antwort bewertet, die erlaubten Lösungswege aber nicht gegen Umgehung absichert, hat Fair Play aufgeschrieben. Durchgesetzt hat er es nicht.

Binnen viereinhalb Tagen wurde aus dem Ausbruch eine verteilte Operation mit mehreren Angriffspfaden und Ausweichkanälen. Daraus folgt kein belastbarer Geschwindigkeitsvergleich mit menschlichen Intrusion-Teams. Das Agentensystem arbeitete unter besonderen Evaluationsbedingungen, mit erheblichem Inferenzaufwand und Tausenden gescheiterten Versuchen. Belegt sind Tempo, Wiederholungsrate und Methodenwechsel, nicht ein allgemeiner Zeitvorteil gegenüber Menschen.

Für die betroffenen Systeme ist ohnehin zweitrangig, dass keine menschliche Schädigungsabsicht belegt ist. Ein gestohlenes Secret bleibt gestohlen. Hochwirksame Angriffe können als Nebenprodukt einer sachlich formulierten Zielverfolgung entstehen, wenn der Angriff ein brauchbarer Weg zum eigentlichen Ziel ist.

Wenn Zero-Days zur Rechenfrage werden

Die bequeme Reaktion wäre, nur die modellseitige Fähigkeit zu beschneiden: schwächere Modelle, mehr Refusals, weniger Rechenbudget. Das kann Risiko senken, repariert aber keine Schwachstelle. Harte Beschränkungen von Werkzeugen, Laufzeit, Identitäten und Egress sind dagegen keine bloßen Verhaltensregeln, sondern Teil der erforderlichen Autoritätsgrenze. Ein Modell, das unbekannte Schwachstellen in unseren Systemen nicht finden darf, macht diese Schwachstellen nicht kleiner. Es senkt nur unsere Chance, sie früh zu sehen.

Maximale Cyberfähigkeit braucht deshalb noch lange keinen unkontrollierten Internetzugang. Fähigkeit und Autorität sind zwei verschiedene Dinge. Ein System darf einen Zero-Day finden, ohne damit das Recht auf einen Ausflug durch fremde Produktionsnetze zu erwerben.

Wenn Exploitentwicklung mit Rechenleistung skaliert, verliert ungepflegte Bestands-IT ihren letzten inoffiziellen Schutz: dass ein Angriff zu teuer, zu kompliziert oder zu langweilig ist. Dann wird IT-Rott nicht plötzlich unsicher. Er war es immer. Neu ist nur, dass seine systematische Erkundung wirtschaftlich wird.

Die Suchenden blind zu machen, repariert keinen einzigen Fehler. Systeme müssen so betrieben werden, als würden ihre unbekannten Schwachstellen tatsächlich gefunden: mit kleinen Blast-Radien, kurzlebigen Identitäten, getrennten Trust Zones, getesteten Rebuilds und Menschen, die für den Betrieb nicht nur auf dem Organigramm verantwortlich sind.

Zero-Days werden damit nicht ausschließlich zu einer Frage von Rechenzentren. Aber Rechenzentren werden zunehmend bestimmen, mit welcher Breite und Geschwindigkeit der vorhandene Fehlerraum durchsucht wird. Sicherheit durch geringe Aufmerksamkeit hat dann endgültig ausgedient.

Der Vorfall erreicht Washington

Der Vorfall hat inzwischen auch die politische Ebene erreicht. Auf eine Frage zu den von OpenAI eingeräumten Zugriffen auf Hugging Face und vier weitere Konten bei öffentlich erreichbaren Diensten erklärte US-Präsident Donald Trump, seine Regierung prüfe „Kontrollen“ für KI-Systeme. Einen konkreten regulatorischen Vorschlag nannte er nicht. Zugleich betonte Trump, amerikanische Unternehmen dürften gegenüber China nicht ausgebremst werden.

Politisch ist das bemerkenswert. Ein Sicherheitskonzept ist es noch lange nicht. Der Vorfall entstand nicht einfach, weil ein Modell zu leistungsfähig war. OpenAI kombinierte offensive Fähigkeiten mit langer Laufzeit und Werkzeugzugriff. Die Evaluation lief ohne Produktionsklassifikatoren für hochriskante Cyberaktivitäten, bei reduzierten Cyber-Refusals und ohne mehrere für den Einsatz vorgesehene Schutzmaßnahmen. Zugleich verließ sich OpenAI auf eine technische Außengrenze, die dem Angriff nicht standhielt.

Falls daraus Regulierung folgt, sollte sie mehr leisten als allgemeine Modellverbote oder freundlichere Antworten im Chatfenster. Hochrisiko-Evaluationen brauchen überprüfbare Regeln für Egress, Zielräume, unabhängige Abbruchpfade, die Zuordnung von Agentenaktivitäten und die Meldung externer Zugriffe. Sonst wird aus einem konkreten Kontrollversagen die nächste diffuse Debatte über „gefährliche KI“. Davon haben wir bereits genug.

Die Grenze muss halten

HDF5-Dateioffenlegung, Template Injection, erreichbare Cloud-Metadaten, privilegierte Pods, überbreite Secrets, wiederverwendete Cluster-Credentials, großzügige VPN-Tags und schreibfähige Integrationen sind keine neue Sicherheitsphysik. Ein fähiger menschlicher Angreifer hätte dieselben Schwächen nutzen können. Der Unterschied lag hier im automatisierten Volumen: 17.600 rekonstruierte Aktionen, viele falsche Wege, schnelle Methodenwechsel und der wiederholte Neuaufbau von Werkzeugen und Kanälen.

Das ist die Praxis hinter Alte Security, schnelle Angreifer und JadePuffer: Der Agent ist der Angreifer. Agentensysteme erfinden gewöhnliche Schwächen nicht neu. Sie testen nur mehr davon, wechseln nach Fehlschlägen die Methode und bauen mit genügend Laufzeit aus vielen kleinen Fehlern eine brauchbare Kette. Für das Zielsystem ist dieser Unterschied eher akademisch.

OpenAI gibt an, dass das eigene Sicherheitsteam die anomale Aktivität intern erkannte. Wann das geschah, welchen Umfang die Erkennung bereits erfasste und welche unmittelbaren Maßnahmen daraus folgten, veröffentlicht das Unternehmen nicht. Hugging Face wiederum berichtet, dass die eigene KI-gestützte Erkennung mehrere Signale korrekt korrelierte, deren Kritikalität aber falsch einstufte und den Bereitschaftsdienst nicht rechtzeitig alarmierte.

Für die Verteidiger verbarg sich der erfolgreiche Pfad zwischen Tausenden schwacher Signale und gescheiterter Versuche. Hugging Face setzte deshalb selbst Modelle zur Rekonstruktion ein. Die Cyberfilter kommerzieller Frontier-APIs blockierten Teile der Analyse; das Unternehmen verwendete schließlich GLM‑5.2 als Open-Weight-Modell auf eigener Infrastruktur. Detektion ohne erzwungene Eskalation bleibt ein Hinweis, keine Grenze.

OpenAI wollte maximale Cyberfähigkeit messen und reduzierte dafür modellinterne Schutzschichten. Genau dann müssen die äußeren Grenzen mehr aushalten als nur den vorgesehenen Testablauf. Ein Egress-Proxy reicht nicht, wenn er selbst ausnutzbare Software ist. Trajektorienüberwachung hilft nur, wenn sie einen unabhängigen Pause- oder Abbruchpfad auslösen kann. Kurzlebige Sandboxes helfen wenig, wenn das System Werkzeuge und C2 bei jedem Lauf neu aufbaut. Ein überbreites Secret oder Connector-Credential kann aus einem Pod mehrere Cluster machen.

Hugging Face hat die beiden Dataset-Vektoren geschlossen, Pod-Zugriff auf Cloud-Metadaten blockiert, Credentials rotiert, Kerninfrastruktur neu aufgebaut, Cluster-Credentials getrennt und die Erkennung verschärft. Das sind Kontrollen. „Das Modell soll so etwas nicht tun“ ist keine. Wir haben es bei Ein Chatfenster ist keine Sicherheitsgrenze allgemeiner formuliert: Sprache beschreibt Regeln. Architektur muss sie durchsetzen.

Wer offensive Agentensysteme auf maximale Zielerreichung testet, muss eine Grenze bauen, die auch dann hält, wenn das System sie als nächste Angriffsfläche behandelt.

Ein Ziel, viele fremde Mittel