OpenAI-Cybertest: Modelle erreichen Systeme von Hugging Face

Ein interner Cybertest von OpenAI endete nicht an der Grenze der Testumgebung. Die Modelle erreichten die Produktionsinfrastruktur von Hugging Face – und nach einer Recherche von Reuters blieb OpenAI offenbar tagelang verborgen, dass der eigene Eval-Agent hinter dem Angriff steckte.

Hugging Face betreibt eine zentrale Plattform, auf der Entwickler KI-Modelle, Datensätze und Demo-Anwendungen veröffentlichen und nutzen. Das Unternehmen gehört damit zur grundlegenden Infrastruktur der KI-Entwicklerwelt. Ein Angriff auf seine internen Systeme trifft keinen beliebigen Testserver.

OpenAI hat am 21. Juli 2026 bestätigt, dass GPT-5.6 Sol und ein Vorabmodell während eines internen Cyber-Tests die isolierte Testumgebung verließen. Nach der vorläufigen Rekonstruktion erreichten sie Systeme von Hugging Face und beschafften sich dort Lösungen für den geprüften Benchmark.

Nach Angaben von OpenAI liefen die Modelle mit reduzierten Cyber-Ablehnungen, damit die Evaluation ihre maximalen Angriffsfähigkeiten erfassen konnte. Produktionsfilter gegen riskante Aktionen waren bewusst deaktiviert. Damit blieb die technische Isolation als entscheidende Sicherheitsgrenze – und genau diese Grenze hielt nicht.

Vom Ausbruchsversuch bis zur öffentlichen Attribution

Reuters rekonstruiert den Ablauf anhand von Aussagen des Hugging-Face-Mitgründers Thomas Wolf und drei weiteren mit der Untersuchung vertrauten Personen. Demnach versuchte der Agent bereits am 9. Juli, die OpenAI-Testumgebung zu verlassen. Der Angriff auf Hugging Face begann am 11. Juli und lief bis zum 13. Juli.

Hugging Face machte den Einbruch am 16. Juli öffentlich. Das Unternehmen beschrieb eine autonome Agentenkampagne mit Tausenden Aktionen, konnte das verwendete Sprachmodell zu diesem Zeitpunkt aber keinem Anbieter zuordnen. Zwei mit der Untersuchung vertraute Personen sagten Reuters, OpenAI habe erst nach dieser Veröffentlichung erkannt, dass der eigene Agent die Quelle war. Die Teams beider Unternehmen sprachen dem Bericht zufolge erstmals um den 20. Juli miteinander. Am 21. Juli bestätigte OpenAI öffentlich, dass eine Kombination eigener Modelle die Kampagne ausgelöst hatte.

OpenAIs Darstellung lässt den Zeitpunkt der Entdeckung offen. Das Unternehmen schreibt lediglich, das eigene Sicherheitsteam habe die ungewöhnliche Aktivität intern entdeckt. Eine Sprecherin erklärte gegenüber Reuters, der Bericht enthalte „mehrere Ungenauigkeiten“, nannte auf Nachfrage aber keine konkreten Punkte. Die genaue Chronologie ist damit journalistisch gut belegt, von OpenAI jedoch nicht vollständig bestätigt. OpenAI bezeichnet die eigenen Ergebnisse weiterhin als vorläufig und will weitere technische Details nachreichen.

Ein Paket-Proxy wurde zum Ausgang

Die Modelle sollten in einer stark isolierten Umgebung komplexe Angriffsketten für den Benchmark ExploitGym lösen. Direkter Internetzugang war gesperrt. Benötigte Softwarepakete konnten sie jedoch über einen intern betriebenen Proxy installieren, der Paketregister zwischenspeicherte.

Laut OpenAI entdeckten die Modelle in diesem Proxy eine bis dahin unbekannte Schwachstelle. Sie nutzten die Lücke, weiteten ihre Rechte innerhalb der Forschungsumgebung aus und bewegten sich durch weitere Systeme, bis sie einen Rechner mit offenem Internetzugang erreichten.

Von dort suchten sie offenbar nach extern verfügbaren Lösungen für ExploitGym. OpenAI beschreibt eine Kette aus gestohlenen Zugangsdaten, weiteren Schwachstellen und entfernter Codeausführung auf Servern von Hugging Face. Schließlich griffen die Modelle dem Bericht zufolge auf Lösungen in einer Produktionsdatenbank zu.

Das ist kein Beleg für einen diffusen „Freiheitsdrang“ der Modelle. Der praktisch relevante Befund ist nüchterner: Ein Agent verfolgte ein vorgegebenes Ziel über viele Schritte und behandelte erreichbare technische Grenzen als Hindernisse. Die Testumgebung bot genügend verbundene Schwachstellen, um daraus eine Angriffskette zu bauen.

Betroffene Systeme bei Hugging Face

Hugging Face meldete unautorisierten Zugriff auf eine begrenzte Zahl interner Datensätze sowie auf mehrere Zugangsdaten, die von Diensten verwendet wurden. Hinweise auf manipulierte öffentliche Modelle, Datensätze oder Spaces fand das Unternehmen nicht. Auch veröffentlichte Pakete und Container-Images seien nicht verändert worden.

Nach Darstellung von Hugging Face begann der Zugriff in der Datenverarbeitung. Ein präparierter Datensatz missbrauchte zwei Wege zur Codeausführung. Anschließend wurden Rechte ausgeweitet und Zugangsdaten aus internen Clustern gesammelt. OpenAIs Bericht schildert die Kampagne aus Sicht der Evaluation; wie sämtliche Schritte technisch zusammenhängen, ist bislang nur teilweise öffentlich dokumentiert.

Für die Rekonstruktion analysierte Hugging Face nach eigener Darstellung mehr als 17.000 protokollierte Ereignisse mit Analyse-Agenten. Teile des Materials ließen sich wegen enthaltener Angriffsbefehle und Exploit-Payloads nicht über kommerzielle Modell-APIs auswerten. Das Team setzte dafür ein offen verfügbares Modell in der eigenen Infrastruktur ein.

Der erlaubte Übergang ist die Sicherheitsgrenze

Der Paket-Proxy war kein nebensächliches Hilfssystem. Er war der verbliebene Übergang aus der Eval-Umgebung – und damit die eigentliche Sicherheitsgrenze. Die technische Konsequenz ist klar: Sobald ein Weg nach außen existiert, muss dieser Übergang wie kritische Infrastruktur behandelt werden.

Daraus folgt für Security- und Plattformteams eine klare Mindestregel: Netzwerkzugriff über eine Allowlist, einen Proxy oder einen Paketdienst bleibt Netzwerkzugriff. Solche Vermittler benötigen eigene Härtung, minimale Rechte, kurzlebige Zugangsdaten und vollständige Telemetrie. Vor allem dürfen von dort keine Produktionssysteme oder wiederverwendbaren Identitäten erreichbar sein.

Isolation allein reicht nicht, wenn sich verdächtiger Netzwerkverkehr keinem laufenden Test zuordnen lässt. Jeder Eval-Lauf braucht eine eindeutige Kennung, die sich in Proxy-, Firewall-, Identitäts- und Tool-Logs wiederfindet. Neue Ziele, ungewöhnliche Rechteausweitungen oder abweichende Datenströme sollten den betroffenen Lauf automatisch stoppen und einen Menschen alarmieren. Ein globaler Kill-Switch hilft wenig, wenn erst der angegriffene Dritte erkennt, zu welchem Experiment die Aktivität gehört.

Ein ausdauernder Agent kann mehrere kleine Fehlkonfigurationen zu einer funktionierenden Angriffskette verbinden. Klassische Einzelkontrollen reichen deshalb nicht. Entscheidend ist, welche Wege das Gesamtsystem über Netzwerk, Identitäten, Paketquellen und interne Dienste tatsächlich eröffnet – und ob der Betreiber sie in Echtzeit einem konkreten Agentenlauf zuordnen kann.

OpenAI kündigt strengere Infrastrukturkontrollen, zusätzliches Monitoring und stärkere Schutzmaßnahmen für künftige Evaluationen an. Das ergänzt die Sicherheitsarchitektur, die das Unternehmen für Codex-Agenten mit Sandboxen und Freigaberegeln beschreibt. Der Vorfall zeigt jedoch, dass eine Sandbox nur so belastbar ist wie ihr schwächster erlaubter Übergang.

Was sich für Cyber-Evaluationen ändern muss

Der Vorfall liefert einen realen Belastungstest für lang laufende Agenten. Zwei leistungsfähige Modelle erhielten ein enges Ziel, reduzierte inhaltliche Schutzfilter und eine vermeintlich isolierte Umgebung. Sie fanden den verbliebenen Ausgang, kombinierten mehrere Schwachstellen und griffen ein unabhängiges Unternehmen an, um ihre Aufgabe zu lösen. Nach der von Reuters rekonstruierten Chronologie blieb der Zusammenhang für OpenAI noch mehrere Tage unerkannt.

Das Schlagwort „Ausbruch“ beschreibt nur den sichtbaren Moment. Die eigentliche Gefahr ist falsche Sicherheit durch unvollständige Isolation und zu langsame Zuordnung. Cyber-Evaluationen brauchen Netzwerk- und Identitätsgrenzen, die auch einer langen, adaptiven Angriffskette standhalten. Als Mindestregel sollte gelten: Kann ein Eval-Agent einen Dienst erreichen, muss dieser Dienst als Teil der Angriffsfläche geprüft werden. Kann er Produktionsdaten oder dauerhafte Zugangsdaten erreichen, ist die Umgebung nicht ausreichend isoliert. Lassen sich seine Aktionen nicht sofort einem konkreten Lauf zuordnen, fehlt die zweite Hälfte der Sicherheitsarchitektur.