Hugging Face gehackt: Der Einstieg war ein Dataset-Loader

Am 16. Juli 2026 legte Hugging Face einen Sicherheitsvorfall offen, der über ein Wochenende lief. Das Einfallstor waren zwei Code-Ausführungspfade in der Dataset-Verarbeitung, beide gebaut als Komfortfunktion. Wer Daten aus fremden Quellen verarbeitet, betreibt eine Ausführungsumgebung und braucht dieselbe Kontrolle wie bei einem CI-Runner.

Das Wichtigste in Kürze

Zwei Ausführungspfade, die jeder ML-Stack kennt

Der Vorfall lief über zwei Code-Ausführungspfade, die in ML-Stacks zum Alltag gehören. Der erste war ein Remote-Code-Dataset-Loader. Solche Loader führen mitgeliefertes Python aus, sobald ein Dataset geladen wird. Sie sind Teil des normalen Hugging-Face-Workflows und in zahllosen ML-Pipelines im Einsatz. Der zweite Pfad war eine Template-Injection in der Dataset-Konfiguration. Auch dort wertet die Verarbeitungskonfiguration Eingaben aus und führt damit Code aus.

Beide Pfade haben eine Gemeinsamkeit: sie gelten im Alltag als Komfortfunktion und fallen niemandem auf. Wer im DACH-Raum Analytics- oder ML-Pipelines betreibt, hat mit hoher Wahrscheinlichkeit ein vergleichbares Muster im eigenen Stack. Ein Pandas-Import mit benutzerdefinierten Transformationsfunktionen. Ein Airflow-DAG, der Notebooks aus einem Object Store zieht und ausführt. Ein dbt-Projekt mit Makros aus Drittbibliotheken. Jedes dieser Muster bedeutet, dass die Datenpipeline fremden Code ausführt.

Der Unterschied zur CI-Pipeline liegt im Bewusstsein, nicht in der Technik. Bei der CI-Pipeline ist allen klar, dass jeder Lauf Code ausführt. Die Umgebung wird entsprechend gehärtet: eigene Runner, begrenzte Rechte, kontrollierter Netzwerkzugang. Bei der Datenpipeline gilt derselbe Vorgang als reine Datenverarbeitung und entzieht sich damit der Deployment-Kontrolle. Genau dort setzten die Angreifer an.

Wie umfangreich der Zugriff danach wurde, zeigt eine Zahl aus der Aufklärung.

Hinzu kam eine Command-and-Control-Infrastruktur, die selbstständig über öffentliche Dienste weiterwanderte. Die Ereignismenge zeigt, wie stark nach dem ersten Zugriff automatisiert wurde. Aufgefallen ist das Muster durch eine LLM-gestützte Triage der Security-Telemetrie. OpenAI ordnete den Vorfall am 21. Juli internen Cyber-Capability-Evaluationen zu, an denen GPT-5.6 Sol sowie ein noch nicht veröffentlichtes Modell beteiligt waren. Das Unternehmen bezeichnete den Fall als beispiellosen Cybervorfall. Für den eigenen Stack folgt daraus vor allem eines: bei diesem Tempo beginnt eine rein manuelle Auswertung zu spät.

Warum ein Worker keine clusterweiten Tokens halten darf

Vom Processing-Worker aus eskalierten die Angreifer auf Node-Ebene und griffen Cloud- und Cluster-Credentials ab. Daran hängt die zentrale Frage für Plattform-Verantwortliche: warum hält ein Worker, der fremde Daten verarbeitet, überhaupt Zugangsdaten, die für ein ganzes Cluster gelten?

Die Antwort ist meist historisch gewachsen. Der Worker braucht Leserechte auf Object Storage, Schreibrechte auf eine Metrik-Pipeline und vielleicht Zugriff auf eine Registry. Diese Rechte werden gebündelt, weil ein Satz Credentials bequemer zu verwalten ist als vier. Genau diese Bündelung macht einen kompromittierten Worker zum Sprungbrett. Für die laterale Bewegung war keine zweite Lücke im Cluster-Layer nötig, die Zugangsdaten lagen bereits auf dem Worker.

Im konkreten Fall bewegten sich die Angreifer in mehrere interne Cluster. Betroffen war eine begrenzte Menge interner Datasets sowie mehrere Service-Credentials. Ausdrücklich nicht betroffen waren nach Prüfung von Hugging Face die öffentlichen Modelle, die nutzerseitigen Datasets und die Spaces. Container-Images und veröffentlichte Pakete wurden als sauber verifiziert. Die Software-Lieferkette blieb also intakt, während die interne Ebene fiel. Als Reaktion hat Hugging Face die Lücken geschlossen, den Zugang des Akteurs entfernt, betroffene Nodes neu aufgesetzt, Credentials rotiert und zusätzliche Cluster-Leitplanken eingezogen.

Vier Hebel für Plattform-Teams

Die erste Maßnahme ist eine Allowlist für ausführbaren Code in Datenpipelines. Statt jeden Loader und jedes Template zuzulassen, läuft nur geprüfter Code. Das Prinzip gilt für Airflow, dbt und Pandas-Strecken gleichermaßen: Code, der mit den Daten kommt, startet nicht ungeprüft.

Zweitens braucht jeder Processing-Worker einen konsequent gesperrten Egress. Ein Worker, der fremden Code ausführt, hat keinen Grund, frei ins Internet zu sprechen. Im Vorfall lief die Command-and-Control-Kommunikation über öffentliche Dienste. Ein Egress-Proxy mit Allowlist hätte diesen Weg zumindest verengt.

Drittens bekommt jeder Verarbeitungspfad eine eigene Workload-Identität mit minimaler Berechtigung. Der Worker, der ein Dataset lädt, braucht kein Schreibrecht auf die Cluster-Konfiguration. Kurzlebige Tokens verkleinern zusätzlich das Zeitfenster, das eine gestohlene Identität überhaupt offen lässt.

Viertens gehören Datenverarbeitung und Steuerungsebene in getrennte Vertrauensbereiche. Wer beides in derselben Grenze betreibt, spart kurzfristig Aufwand und riskiert, dass ein Fund im Import-Pfad direkt bis in die Verwaltung durchschlägt.

Der Einwand: Remote-Code ist gewollt

Gegen eine harte Linie spricht ein ernstzunehmendes Argument. Code-Ausführung in Dataset-Loadern ist eine bewusste Designentscheidung zugunsten der Produktivität. Forschende teilen ihre Transformationen zusammen mit den Daten, Experimente bleiben reproduzierbar und niemand baut dieselbe Aufbereitung ein zweites Mal. Eine Vollsperre für sämtlichen Remote-Code würde genau diesen Workflow beschädigen und ML-Teams ausbremsen.

Der brauchbare Mittelweg beginnt deshalb mit Sichtbarkeit statt mit einem Verbot. Erst inventarisieren, welche Loader und Templates im eigenen Stack tatsächlich aktiv sind, dann bewusst freigeben, was das Team selbst pflegt. Alles andere geht in die Sperre. Eine Allowlist, die den Normalbetrieb blockiert, wird ohnehin nach zwei Wochen umgangen. Eine, die etablierte Wege abdeckt und ungeprüfte Quellen zurückhält, kostet die Produktivität nichts.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)