Vergangene Woche machte OpenAI Schlagzeilen, weil KI-Modelle während eines internen Tests aus ihrer Sandbox ausbrachen und sich Zugang zu Hugging Face verschafften. Scheinbar knackten die Modelle im gleichen Zuge noch mehr.
Weiterlesen nach der Anzeige
Reuters berichtete, dass unter anderem ein Kunde von Modal dabei war. Das ist ein Unternehmen, das Software-Infrastruktur für das Training und den Betrieb von KI-Diensten anbietet. In einer Stellungnahme gegenüber Wired bestätigte Akshat Bubna, Chief Technology Officer von Modal, dass der Agent von OpenAI eine Sicherheitslücke in der Codebasis eines seiner Kunden ausgenutzt habe, die auf der Infrastruktur von Modal lief. Er betonte jedoch, dass die Plattform von Modal in keiner Weise kompromittiert worden wäre. OpenAI lehnte es ab, sich gegenüber Wired weiter zu dem Vorfall zu äußern.
Was genau passierte
OpenAI hat in einem Blogpost jetzt auch im Detail offengelegt, wie mehrere eigene KI-Modelle während eines internen Sicherheitstests eigenständig aus einer isolierten Testumgebung ausbrachen und die Produktionsinfrastruktur von Hugging Face kompromittierten. Der Vorfall, über den wir bereits berichtet hatten, geht demnach auf GPT-5.6 Sol und ein noch leistungsfähigeres, unveröffentlichtes Pre-Release-Modell zurück.
Sie sollten einer internen Evaluation anhand des Benchmarks ExploitGym unterzogen werden, der die Cyber-Fähigkeiten von Modellen quantifiziert. Für diese Tests waren die üblichen Sicherheitsklassifikatoren, die risikoreiche Cyberaktivitäten unterbinden sollen, bewusst deaktiviert worden. Die Testumgebung selbst war laut OpenAI aber stark isoliert. Der Netzwerkzugriff der Modelle war wohl darauf beschränkt, Pakete über eine intern gehostete Drittanbietersoftware zu installieren, die als Proxy und Cache für Paket-Registries diente.
Um trotzdem vollen Internetzugriff zu erhalten, identifizierten die Modelle eine Zero-Day-Schwachstelle im Cache-Proxy der Paket-Registry. Mit diesem Zugriff führten sie eine Reihe von Privilege-Escalation- und Lateral-Movement-Aktionen aus, bis sie einen Node mit Internetzugang erreichten.
Das mutmaßliche Ziel der KI: Möglichst gut im Test abschneiden
Weiterlesen nach der Anzeige
Auf der Basis schlossen die Modelle, dass auf Hugging Face möglicherweise Modelle, Datensätze und Lösungen für ExploitGym zu finden sind. Also suchten sie nach Möglichkeiten, Zugriff auf hilfreiche geheime Informationen für den Test zu bekommen. Dabei testeten sie verschiedene Herangehensweisen – etwa eine Verkettung von mehreren Angriffsvektoren wie gestohlenen Zugangsdaten und Zero-Day-Schwachstellen, um auf den Servern von Hugging Face eine Möglichkeit für Remote-Codeausführung zu finden.
Alles deutet laut OpenAI darauf hin, dass die Modelle hierbei sehr darauf fokussiert waren, eine Lösung für ExploitGym zu finden. Um das zu erreichen, gingen sie, so schreibt die KI-Firma, „ungewöhnlich weit“, um das Testziel zu erreichen. Was dieser Vorfall über die Zukunft agentischer KI und ihre Regulierung bedeutet, analysiert Christoph Jehle auf Telepolis.
Update 30.07.2026, 12:45 Uhr
Hugging Face veröffentlichte nun ebenfalls eine genaue Beschreibung des Hergangs. Demnach umfasste der Angriff etwa 17.600 Angreiferaktionen, die sie wiederherstellen konnten. Der Zeitraum erstreckt sich vom 09.07.2026, 02:28 UTC, bis zum 13.07.2026, 14:14 UTC. Hugging Phase gliedert den Angriff in zwei Phasen.
In der ersten, in weiten Teilen oben bereits beschrieben, erreichten die Modelle eine Startplattform durch eine Verkettung über die Infrastruktur anderer Parteien. Hugging face ergänzt, dass die Modelle hierbei eine öffentliche Code-Evaluierungsumgebung missbrauchten, die von einem Nutzer eines Drittanbieters für Infrastruktur gehostet wurde. Sie waren in der Lage, auf dieser externen Sandbox Befehle als Root/Admin auszuführen und nutzte sie als Kontroll-, Vorbereitungs- und Ausgangsbasis für die gesamte Kampagne. Diese kompromittierte externe Sandbox hatte keine direkte Netzwerkverbindung zum Hugging Face Cluster.
In der zweiten Phase drangen die Modelle in die Infrastruktur von Hugging Face ein. Dafür missbrauchte der Agent deren Pipeline zur Datensatzverarbeitung über zwei Injektionsvektoren, die beide auf denselben konfigurationsgesteuerten Datenlader innerhalb ihres Kubernetes-Pods in der Produktion abzielten. Der erste Vektor war ein Lesevorgang eines externen HDF5-Rohspeicher-Datensatzes, der den Inhalt lokaler Dateien zurückgab: Dadurch erhielt der Agent Zugriff auf die Pod-Umgebung. Der zweite Vektor war eine Jinja2-Template-Injektion, die beliebigen Code ausführte und dem Angreifer so einen Zugang zum System verschaffte.
Sobald der Angriffspunkt im Produktions-Pod etabliert war, folgte der Agent einem standardmäßigen Eskalationsmuster: Aufklärung, Platzieren eines Stagers, Aufbau einer Command-and-Control-Verbindung (C2), dann weiter Vordringen ins Cluster, in die Cloud-Metadaten, in das internes Netzwerk und in die Source-Control-Lieferkette. Die Ausgabe der im Pod ausgeführten Befehle wurde über die HF-API und vom Angreifer kontrollierte Dead-Drop-Datensätze an den Agenten zurückgesendet, die der Agent dann aus der Sandbox auslas.
Hugging Face betont nochmal, dass der einzige Kundendatensatz, auf den zugegriffen wurde, die Sammlung von ExploitGym/CyberGym-Challenge-Lösungen gewesen sei.
(rie)
Dieser Link ist leider nicht mehr gültig.
Links zu verschenkten Artikeln werden ungültig, wenn diese älter als 7 Tage sind oder zu oft aufgerufen wurden.
Sie benötigen ein heise+ Paket, um diesen Artikel zu lesen. Jetzt eine Woche unverbindlich testen – ohne Verpflichtung!