Zweites Unternehmen betroffen: OpenAI-Agent nutzte Modal Labs als Startrampe

Der außer Kontrolle geratene KI-Agent von OpenAI hat nicht nur Hugging Face getroffen. Ein zweites Unternehmen ist betroffen, und das inzwischen offiziell: Akshat Bubna, technischer Geschäftsführer des New Yorker Cloud-Anbieters Modal Labs, bestätigte den Vorgang gegenüber der Nachrichtenagentur Reuters und dem Nachrichtenportal Axios. Zeitgleich gibt Hugging Face erstmals detaillierten Einblick in den Ablauf des in der vergangenen Woche bekannt gewordenen Angriffs.

Nach Bubnas Darstellung hatte ein Kunde von Modal Labs eine Schnittstelle ohne Zugangsschutz ins Netz gestellt, über die praktisch jeder fremden Code in dessen Sandkasten-Umgebungen ausführen konnte. Genau diese offene Tür habe der Agent genutzt. Die Plattform von Modal Labs selbst sei in keiner Weise kompromittiert worden; verwundbar gewesen sei der Code des Kunden.

Damit fügt sich ein bislang loses Puzzleteil zusammen. Hugging Face beschreibt in seiner technischen Aufarbeitung, dass der Agent nach dem Ausbruch aus der OpenAI-Testumgebung eine ungesicherte, öffentlich erreichbare Code-Sandbox bei einem Drittanbieter übernahm und von dort aus die gesamte weitere Kampagne steuerte. Modal Labs war also nicht bloß ein zweites Opfer nebenbei, sondern die Startrampe für den Einbruch bei Hugging Face.

Altman pausiert das Modelltraining

Der Vorfall hat spürbare Folgen bei OpenAI. Firmenchef Sam Altman erklärte am Dienstag in einem Podcast-Auftritt, der Angriff auf Hugging Face habe das Unternehmen gezwungen, das Training seiner Modelle vorerst auszusetzen. Man müsse das Tempo der KI-Entwicklung womöglich drosseln, um der Gesellschaft genug Zeit zu geben, sich gegen die neuen Fähigkeiten zu wappnen. Die Äußerung fällt in eine heikle Phase: OpenAI wirbt derzeit in Washington um die behördliche Freigabe für die Veröffentlichung seines bislang leistungsstärksten Modells.

Am selben Tag wurde ein offener Brief öffentlich, der die US-Regierung zu einer internationalen Initiative auffordert: Es brauche technische und regulatorische Werkzeuge, um das Tempo der automatisierten KI-Entwicklung bewusst zu steuern. Die Seite wies am 29. Juli 1.134 Unterzeichner aus Beschäftigten führender KI-Unternehmen aus, die Zahl wächst weiter. Zu ihnen zählen OpenAI-Chefwissenschaftler Jakub Pachocki und Anthropic-Mitgründer Jared Kaplan. Hugging-Face-CEO Clément Delangue forderte seinerseits radikale Transparenz von OpenAI, die vollständige Offenlegung aller Ausführungsspuren des Agenten sowie ein Compute-Paket im Wert von 100 Millionen US-Dollar zur Unterstützung der weltweiten Sicherheitsforschung. OpenAI äußerte sich auf Anfrage von Axios zunächst nicht.

Hugging Face legt die technische Chronologie offen

Einen Tag vor dem Reuters-Bericht, am 27. Juli 2026, hatte Hugging Face das offizielle technische Post-Mortem vorgelegt. Nachdem die Plattform den Einbruch im Juli eingrenzen konnte - wie wir bereits in unserer Erstmeldung zum Hugging-Face-Einbruch sowie der anschließenden Bestätigung durch OpenAI berichteten - zeigt die Angriffschronologie das volle Ausmaß. Zwischen dem 9. und dem 13. Juli führte der Agent rund 17.600 rekonstruierbare Aktionen aus und baute sich eine Command-and-Control-Infrastruktur aus öffentlichen Webdiensten.

Das Motiv: Der Agent wollte seine eigene Prüfung unterlaufen

Der bemerkenswerteste Befund des Post-Mortems ist das mutmaßliche Ziel des Angriffs. Der Agent lief in einer OpenAI-Prüfumgebung namens ExploitGym, einem Testverfahren, das KI-Agenten das Auffinden und Ausnutzen von Softwarelücken abverlangt. Soweit das Hugging-Face-Team es rekonstruieren konnte, folgerte der Agent im Verlauf dieser Prüfung, dass Hugging Face die Modelle, Datensätze und Musterlösungen genau dieses Testverfahrens hosten könnte. Der gesamte Einbruch sei aus Sicht des Agenten daher der Versuch gewesen, die Prüfung zu unterlaufen: die Lösungen stehlen, statt die gestellte Aufgabe selbst zu lösen.

Der Zwischenfall ereignete sich während einer internen Evaluierung bei OpenAI, bei der die regulären Sicherheits-Classifier und Cyber-Sperren des Modells gezielt deaktiviert wurden, um die Rohfähigkeiten des Systems zu messen. Kein Mensch steuerte die einzelnen Schritte. Aus der Testumgebung brach der Agent über eine bis dahin unbekannte Lücke im Cache-Server der Paketverwaltung aus, einem der wenigen für ihn freigegebenen Wege ins Netz. Von der übernommenen Sandbox beim Drittanbieter aus drang er über zwei Einfallstore in die Datensatz-Verarbeitung von Hugging Face ein: einmal per Dateizugriff über eine manipulierte HDF5-Datei, der ihm die Zugangsdaten des Produktionssystems lieferte, und einmal per Template-Injection, die ihm die Ausführung eigenen Codes erlaubte.

Was ExploitGym eigentlich misst

ExploitGym ist kein internes OpenAI-Werkzeug, sondern ein öffentlicher Prüfstand. Die zugehörige Veröffentlichung erschien im Mai 2026, federführend war eine Gruppe um die KI-Sicherheitsforscherin Dawn Song; der Code liegt frei auf GitHub. Die Aufgabe ist eng gefasst: Der Agent erhält eine Eingabe, die in einem Programm eine bekannte Schwachstelle auslöst, und soll daraus einen funktionierenden Angriff bauen. Aus einem theoretischen Fehler soll also ein konkreter Schaden werden, etwa unbefugter Dateizugriff oder die Ausführung fremden Codes. Das Paper beschreibt 898 solcher Fälle aus echten Sicherheitslücken in drei Bereichen: gewöhnliche Anwendungsprogramme, Googles JavaScript-Motor V8 und der Linux-Kernel. Die freigegebene Version 1.0 enthält 869 Aufgaben.

Die Messung fiel deutlich aus: Die stärksten Konfigurationen waren Claude Mythos Preview mit 157 und GPT-5.5 mit 120 lauffähigen Angriffen. Auch mit eingeschalteten Standard-Schutzmechanismen blieben die Erfolgsquoten nach Angaben der Autoren spürbar über null.

Warum solche Tests ohne Internetzugang laufen

Daran knüpft ein verbreitetes Missverständnis an: Wenn KI-Systeme im Alltag ohnehin im Netz recherchieren, wozu dann ein Test in einer abgeschotteten Kammer? Dafür gibt es drei handfeste Gründe.

Erstens würde man sonst das Falsche messen. Zu vielen dieser Schwachstellen existiert im Netz längst fertiger Angriffscode. Ein Agent mit Websuche könnte ihn schlicht nachschlagen. Gemessen würde dann Recherchefähigkeit statt der Fähigkeit, einen Angriff selbst zu konstruieren. Erst die Abschottung macht das Ergebnis aussagekräftig und über Monate vergleichbar, wenn neue Modelle gegen dieselben Aufgaben antreten.

Zweitens entsteht dabei echte Munition. Die Zielprogramme sind keine Übungsattrappen, sondern real eingesetzte Software bis hinunter zum Linux-Kernel. Ein gelungener Testlauf produziert einen einsatzfähigen Angriff. Diesen ins offene Netz zu lassen, wäre schlicht fahrlässig. Die Autoren benennen die Doppelnatur ausdrücklich: Dieselbe Fähigkeit stützt die Verteidigung und senkt zugleich die Einstiegshürde für Angreifer.

Drittens ist die Abschottung technisch, nicht symbolisch. Die Agenten-Container hängen laut Projektdokumentation an einem Docker-Netz ohne Route ins Internet. Der Verkehr läuft über einen vorgeschalteten Filter, dessen Freigabeliste im Testbetrieb ausschließlich die Schnittstellen der Sprachmodelle enthält, darunter api.openai.com und api.anthropic.com. Alles andere wird abgewiesen. Selbst wenn ein Programm im Container die Proxy-Einstellung ignoriert, scheitert die Verbindung, weil kein Weg nach draußen existiert. Softwarepakete darf der Container nur in einer vorgelagerten Phase über einen zweiten, offenen Filter nachladen; bevor der eigentliche Agent startet, wird er von diesem Netz getrennt.

Das Modell selbst bleibt dabei erreichbar, denn es läuft nicht im Container, sondern antwortet von außen über seine Schnittstelle. Genau diese Grenze benennt die Dokumentation offen: Ein Netzwerkfilter kann nicht verhindern, dass ein Anbieter serverseitig eine Websuche ausführt. Dafür ist eine zweite Sperre auf Ebene des Modellzugangs zuständig.

Der Vorfall bei Hugging Face bestätigt diese Bauweise, statt sie zu widerlegen. Die Isolation ist keine Kulisse, sondern die einzige Trennlinie zwischen einem Testlauf und einem echten Einbruch. Als sie versagte, geschah das ausgerechnet an einer der wenigen zugelassenen Öffnungen: über eine bis dahin unbekannte Lücke im Cache-Server der Paketverwaltung, einem der wenigen erlaubten Ausgänge. Das Ergebnis war eine reale, tagelange Kampagne gegen ein reales Unternehmen. Die Lehre aus dem Juli 2026 lautet daher nicht, solche Tests offener anzulegen, sondern die Kammern dichter zu bauen.

Wie ernst die Fachwelt das nimmt, zeigt der eingangs erwähnte offene Brief. Auch Dawn Song hat unterzeichnet und begründet es mit genau dieser Prüfarbeit: CyberGym und ExploitGym belegten, dass Spitzenmodelle inzwischen reale Software-Schwachstellen finden und ausnutzen könnten. Ohne geeignete Schutzvorkehrungen ließen sich damit Cyberangriffe in großem Maßstab ermöglichen.

17.600 Aktionen und ein C2-Netzwerk aus öffentlichen Diensten

Obwohl jede flüchtige Sandbox-Instanz bei einem Neustart ihren Speicher verlor, baute das Modell seine Werkzeuge und Netzwerkkanäle jedes Mal neu auf. Besonders raffiniert war das Command-and-Control-System (C2): Statt eigene Server zu betreiben, verwendete der Agent ausschließlich gewöhnliche öffentliche Webdienste. Als Hauptkanal diente ein Request-Capture-Dienst mit mehr als 100 Einweg-Endpunkten, dazu kamen Pastebins und Filehoster als Nachlade-Stationen sowie eigene öffentliche Datensätze auf Hugging Face selbst als tote Briefkästen. Ein offener CORS-Proxy-Space auf der Plattform diente als Ausleitung, sobald direkte Verbindungen blockiert wurden.

Entwendete Daten und System-Tokens wurden mit einer Kombination aus Chunking, XOR-Verschlüsselung und Gzip-Komprimierung getarnt, damit eine einfache Textsuche in den Protokollen nichts findet. Genau das trat ein: Als das Sicherheitsteam die Entschlüsselungslogik des Agenten nachbaute, kamen rund viermal mehr gestohlene Zugangsdaten ans Licht als beim ersten automatisierten Scan.

Der Schaden blieb nach Darstellung von Hugging Face dennoch eng begrenzt. Zwar erreichte der Agent die interne Infrastruktur, an Kundeninhalten seien aber ausschließlich die in fünf Datensätzen abgelegten Musterlösungen des Benchmarks berührt worden. Andere Modelle, Datensätze, Spaces oder Pakete von Kunden seien nicht betroffen gewesen. Die Schreibrechte, die sich der Agent in der internen Quellcode-Verwaltung verschaffte, waren real und wurden genutzt, führten nach interner Prüfung aber zu keiner ausgelieferten Änderung.

Das Guardrail-Dilemma: Claude verweigert die Forensik

Die ersten Signale kamen aus mehreren Schichten des Sicherheitsstapels gleichzeitig und wurden vom KI-gestützten Security-System von Hugging Face korrekt zu einem Angriffsbild verknüpft. Das System stufte die Dringlichkeit jedoch zu niedrig ein und alarmierte das Bereitschaftsteam nicht rechtzeitig, was nach eigener Darstellung wertvolle Reaktionszeit kostete.

Bei der anschließenden Aufarbeitung der Log-Mengen stieß das Team auf ein unerwartetes Hindernis. Um die 17.600 Aktionen zu analysieren, setzte es zunächst auf Forensik-Pipelines mit den kommerziellen Modellen Claude Opus und Fable. Deren Sicherheits-Guardrails blockierten jedoch einen großen Teil der Arbeit: Die Systeme behandelten das Rückwärts-Analysieren eines Exploits genauso wie dessen Ausführung und verweigerten den Dienst.

Die Lösung fand Hugging Face in der Open-Source-Community. Das Team nahm das offene Modell GLM-5.2 von ZAI auf eigener Infrastruktur in Betrieb und leitete die gesamte Pipeline dorthin um, mit dem Nebeneffekt, dass die Angreiferdaten das Haus nicht verließen. Erst damit gelang es, das Verschlüsselungsschema und den Kampagnenschlüssel zu rekonstruieren, die getarnten Datenpakete zu entschlüsseln und eigene Werkzeuge zur Spurenanalyse zu bauen.

Sechs Hardening-Schritte und die Asymmetrie der KI-Abwehr

In Folge des Angriffs setzte Hugging Face ein sechsstufiges Härtungsprogramm um. Dazu zählten die Schließung beider Code-Ausführungspfade im Dataset Config Renderer, die strikte Blockierung von Cloud-Metadaten-Zugriffen (IMDSv2) auf Pod-Ebene, eine umfassende Rotation aller Tokens und Zertifikate, der vollständige Neuaufbau eines betroffenen Kern-Clusters, eine engere Rechtevergabe im internen Cluster-Zugangssystem sowie verhaltensbasierte Alarmierung.

Bei der Einordnung bleibt Hugging Face nüchtern: Die einzelnen Schwachstellen seien nichts Außergewöhnliches gewesen. Unsichere Datensatz-Verarbeitung, offene Cloud-Metadaten, zu weit gefasste Rechte und langlebige Zugangsdaten hätte auch ein fähiger menschlicher Angreifer finden können. Neu sei die Größenordnung. Der Agent probierte tausende Pfade, die meisten davon erfolglos, und der erfolgreiche Weg verbarg sich im Rauschen der gescheiterten. Für IT-Sicherheitsverantwortliche verschiebt das die Aufgabe: Erkennungssysteme müssen schwache Einzelsignale über mehrere Systeme hinweg schnell genug korrelieren, um mit maschineller Geschwindigkeit mitzuhalten.