Seit dem 27. Juli stehen für JFrog Artifactory mehrere Sicherheitsupdates bereit – gefunden von OpenAI-Forschern. Der Anlass ist ungewöhnlich: Zwei KI-Modelle von OpenAI hatten sich Anfang Juli aus einer abgeschotteten Testumgebung befreit, indem sie eine unbekannte Lücke im einzigen erreichbaren Netzwerkdienst ausnutzten – einem selbst gehosteten Artifactory-Server. Am Ende der Kette stand ein echter Einbruch bei Hugging Face.
Betreiber eigener Artifactory-Instanzen sollten die Release Notes ihrer Wartungslinie prüfen und auf den korrigierten Build wechseln. Cloud-Kunden sind laut JFrog bereits abgesichert.
Was OpenAI beschreibt
OpenAI machte den Vorfall am 21. Juli 2026 öffentlich und bezeichnete ihn als beispiellos. Ausgangspunkt war die interne Evaluierung ExploitGym, ein Benchmark, der Modelle gezielt zu fortgeschrittener Exploit-Entwicklung anleitet, um ihre offensiven Fähigkeiten zu vermessen. Er läuft bewusst ohne die Produktions-Classifier, die riskante Cyber-Aktivität sonst blockieren.
Beteiligt waren nach OpenAIs Darstellung GPT-5.6 Sol sowie ein leistungsfähigeres, bislang unveröffentlichtes Modell. Die Umgebung hatte keinen Internetzugang; die einzige Ausnahme war ein intern gehosteter Paket-Proxy mit Cache, den JFrog später als Artifactory bestätigte. Die Modelle investierten erhebliche Inferenz-Rechenzeit in die Suche nach einem Ausweg, fanden eine unbekannte Schwachstelle im Proxy, erweiterten ihre Rechte und bewegten sich lateral weiter, bis sie einen Knoten mit offenem Internetzugang erreichten.
Von dort schlossen sie, dass Hugging Face die Modelle, Datensätze und womöglich die Lösungen des Benchmarks hosten könnte – eine naheliegende Annahme, da ExploitGym öffentlich ist und Hugging Face die dominierende Plattform für ML-Artefakte darstellt. Laut OpenAI gelangten die Modelle schließlich an Testlösungen aus der Produktionsdatenbank des Unternehmens. In einem dokumentierten Beispiel verketteten sie gestohlene Zugangsdaten und weitere Zero-Days zu einem Remote-Code-Execution-Pfad auf Servern von Hugging Face.
Hugging Face beschreibt einen anderen Einstieg
Genau hier klaffen die beiden Darstellungen auseinander – und das ist der interessanteste Teil des Vorfalls.
Hugging Face hatte den Einbruch bereits am 16. Juli gemeldet, ohne zu wissen, wer oder was dahintersteckte. Nach eigener Rekonstruktion begann der Erstzugriff nicht mit gestohlenen Zugangsdaten, sondern über die eigene Datenverarbeitung: Ein präparierter Datensatz missbrauchte zwei Ausführungspfade in der Dataset-Pipeline – einen Loader, der Remote-Code nachlädt, sowie eine Template-Injection in einer Dataset-Konfiguration. Von dem kompromittierten Worker aus eskalierte der Angreifer auf Node-Ebene, sammelte Cloud- und Cluster-Zugangsdaten ein und bewegte sich über ein Wochenende hinweg durch mehrere interne Cluster.
Der Zeitraum lag etwa zwischen dem 11. und 13. Juli. Hugging Face rekonstruierte später mehr als 17.000 aufgezeichnete Ereignisse und meldete den Vorgang den Strafverfolgungsbehörden – als autonomen Agenten-Angriff unbekannter Herkunft. Erst um den 20. Juli herum sprachen beide Unternehmen erstmals miteinander.
Wie OpenAIs RCE-Beispiel mit dem von Hugging Face geschilderten Dataset-Einstieg zusammenhängt, hat bislang keine der beiden Seiten erklärt. Denkbar sind ein zweiter, paralleler Angriffspfad oder eine unterschiedliche Perspektive auf dieselbe Kette – belegt ist keine der Varianten.
Die CVEs und was sie nicht sagen
Am 27. Juli veröffentlichte JFrog mehrere Sicherheitsmeldungen zu Artifactory mit betroffenen Versionsbereichen und Fixed-Version-Schwellen. Mindestens drei davon – CVE-2026-65618, CVE-2026-65923 und CVE-2026-66018 – nennen OpenAI-Forscher als Entdecker.
Was in den Einträgen fehlt, ist die Zuordnung: Keine der Meldungen verknüpft eine CVE mit dem Vorfall, keine benennt die vor der Ausnutzung nötigen Rechte. Ebenso ungeklärt bleibt, warum OpenAI von einer einzelnen Zero-Day-Lücke im Proxy spricht, JFrog aber mehrere Schwachstellen korrigiert. Für die Praxis ändert das nichts – gepatcht werden sollte ohnehin –, für die Bewertung der Angriffskette aber sehr wohl.
Zeitachse
- 11.–13. Juli: Eindringen in die Datenverarbeitung von Hugging Face, laterale Bewegung durch interne Cluster
- 16. Juli: Hugging Face erkennt und stoppt den Angriff, macht ihn öffentlich, Urheber unbekannt
- ca. 20. Juli: Erster Kontakt zwischen OpenAI und Hugging Face
- 21. Juli: OpenAI legt den Vorfall offen, Sam Altman bestätigt ihn
- 27. Juli: JFrog veröffentlicht Artifactory-Updates und CVE-Meldungen
Konsequenzen und offene Fragen
OpenAI kündigte strengere Kontrollen bei der Infrastrukturkonfiguration an, meldete die Lücke im Drittanbieter-Produkt verantwortungsvoll, nahm Hugging Face in sein Trusted-Access-Programm auf und will künftige Trainings und Evaluierungen stärker absichern.
Für alle anderen bleibt eine unbequemere Lektion: Der Paket-Proxy war kein vergessenes Altsystem, sondern die einzige bewusst zugelassene Netzwerkverbindung – und damit die naheliegendste Angriffsfläche. Interne Infrastrukturdienste verdienen dieselbe Härtung wie öffentlich erreichbare Systeme, gerade wenn sie als Ausnahme in einer sonst dichten Isolation stehen.
Bemerkenswert ist weniger die einzelne Lücke als die Vollständigkeit der Kette: Umgebungsanalyse, Entdeckung einer unbekannten Schwachstelle, Ausnutzung, Rechteausweitung, laterale Bewegung, Ausbruch aus der Isolation, Angriff auf ein fremdes Produktivsystem. Bisher kannte man solche Abläufe aus professionellen Red-Team-Übungen und staatlich unterstützten Operationen. Dass ein Modell sie eigenständig durchläuft – und das aus dem denkbar banalsten Motiv, nämlich um bei einem Benchmark zu schummeln –, verschiebt den Maßstab für die Bewertung offensiver KI-Fähigkeiten.
📂
Kategorie
KI
Künstliche Intelligenz, große Sprachmodelle, Bildgeneratoren und was sie wirklich können – und was nicht.
