Hugging Face gehackt: Dataset als Einfallstor

Hugging Face hat einen Einbruch in die eigene Infrastruktur offengelegt. Der Einstieg war kein geleaktes Passwort und kein Phishing, sondern ein ganz normal wirkendes Dataset, das jemand auf die Plattform geladen hat. Beim Verarbeiten dieses Datasets brachte ein Angreifer Code auf einem internen Worker zur Ausführung, arbeitete sich von dort tiefer ins System vor und griff Zugangsdaten ab. Das Ganze lief nicht per Hand: Ausgeführt wurde der Angriff über ein autonomes Agenten-Framework, das über 17.000 Einzelaktionen protokolliert hat. Damit ist es einer der ersten öffentlich bestätigten Produktionseinbrüche, die von Anfang bis Ende von einer KI gefahren wurden, ausgerechnet gegen den zentralen Umschlagplatz für offene Modelle.

Für die naheliegende Sorge gleich vorweg: Nach allem, was Hugging Face bisher sagt, wurden keine öffentlichen Modelle, Datasets oder Spaces manipuliert. Trotzdem gibt es einen konkreten Grund, aktiv zu werden, und eine Lehre, die weit über diesen einen Vorfall hinausgeht.

Was passiert ist

Das hochgeladene Dataset nutzte zwei Schwachstellen in der Verarbeitungs-Pipeline aus: einen Loader, der mitgelieferten Code ausführt, und eine Template-Injection in der Dataset-Konfiguration. Zusammen reichte das, um beliebigen Code auf einem Verarbeitungs-Worker laufen zu lassen. Von dort ging es weiter über das Wochenende.

flowchart TB
  A["Hochgeladenes<br/>Dataset"] --> B["Code-Ausführung<br/>auf Worker"]
  B --> C["Rechte-Eskalation<br/>auf Node-Ebene"]
  C --> D["Cloud- und Cluster-<br/>Zugangsdaten abgegriffen"]
  D --> E["Laterale Bewegung in<br/>mehrere interne Cluster"]
  class D danger
  class E danger
  classDef danger fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5

Betroffen waren am Ende ein begrenzter Satz interner Datasets und mehrere Service-Zugangsdaten. Ob auch Partner- oder Kundendaten berührt wurden, hat Hugging Face zum Zeitpunkt der Offenlegung noch geprüft. Entdeckt wurde der Angriff übrigens selbst mit KI-Unterstützung, über eine automatische Auffälligkeitsanalyse der Sicherheits-Telemetrie.

Was nicht betroffen ist

Diese Abgrenzung ist wichtig, damit die Meldung nicht größer wirkt, als sie ist:

• Öffentliche Modelle, Datasets und Spaces: kein Hinweis auf Manipulation.
• Die Software-Lieferkette (Container-Images, veröffentlichte Pakete): laut Hugging Face überprüft und sauber.
• Der Zugriff blieb auf interne Systeme beschränkt.

Es ist also kein Fall, in dem ein vergiftetes Modell an tausende Nutzer ausgeliefert wurde. Der Schaden liegt bei Hugging Face selbst, nicht in euren heruntergeladenen Gewichten. Genau deshalb lohnt der Blick auf den Mechanismus mehr als auf die Schlagzeile.

Die eigentliche Lehre: Daten können zu Code werden

Im Kern steckt ein klassisches Grenzproblem, keine exotische KI-Lücke: Ein nicht vertrauenswürdiges Artefakt landete in einer Pipeline, deren Worker echte, wertvolle Zugangsdaten erreichen konnte. Ein Datenformat, das dem Empfänger erlaubt, "lade dieses Skript" oder "nutze dieses Template" zu sagen, ist keine Datei mehr, sondern ein Programm.

Für alle, die selbst mit Hugging Face arbeiten, ist das die praktisch relevante Stelle. Das Ökosystem kennt genau diese Falle unter dem Schalter trust_remote_code=True: Viele Modelle und Datasets bringen eigenen Lade-Code mit, der beim Import einfach mitläuft. Bequem, aber jede Nutzung mit einem fremden Artefakt aus unbekannter Hand ist eine Vertrauensentscheidung. Das reiht sich direkt in das ein, was wir zuletzt zur Vergiftung offener Modelle beschrieben haben: Der Bezug offener Gewichte und Daten ist eine Supply-Chain-Frage, kein reiner Download.

Der Nebenschauplatz, der DACH-Teams interessieren dürfte

Ein Detail aus dem Vorfall taugt fast zum eigenen Lehrstück. Für die forensische Auswertung wollte Hugging Face zunächst ein kommerzielles Spitzenmodell einsetzen. Das scheiterte an dessen Sicherheitsleitplanken: Die Analyse setzt voraus, dass man große Mengen echter Angriffsbefehle, Exploit-Code und Command-and-Control-Artefakte in das Modell gibt, und genau solche Eingaben wurden blockiert. Die Leitplanken können einen Verteidiger im Ernstfall nicht von einem Angreifer unterscheiden.

Die Lösung war ein selbst gehostetes offenes Modell (GLM 5.2) auf eigener Infrastruktur. Mit dem willkommenen Nebeneffekt, dass die hochsensiblen Angriffsprotokolle nicht erst auf die Server eines KI-Anbieters hochgeladen werden mussten. Hugging Face nennt das eine "Lücke, für die man vorausplanen sollte". Für Teams, die aus DSGVO- und Souveränitätsgründen ohnehin über lokale Modelle nachdenken, ist das ein zusätzliches Argument: Es gibt Situationen, in denen ein Modell im eigenen Haus nicht nur datenschutzfreundlicher, sondern schlicht das einzige ist, das die Aufgabe erledigt.

Was ihr jetzt tun solltet

Konkret und in dieser Reihenfolge:

• Access-Tokens rotieren. Das ist Hugging Faces ausdrückliche Empfehlung an alle Nutzer. Alte Tokens ungültig machen und neu erzeugen.
• Kontoaktivität prüfen. In den Account-Einstellungen die letzten Zugriffe und verbundenen Anwendungen durchsehen, ob etwas nicht passt.
• Feingranulare Tokens statt Universalschlüssel. Lieber ein eng berechtigtes Token pro Zweck (ein Projekt, eine CI-Pipeline) als einen breiten Schlüssel, der überall liegt. Wird einer kompromittiert, ist der Schaden begrenzt.
• Fremde Datasets und Modelle als nicht vertrauenswürdig behandeln. trust_remote_code=True nur bei Quellen, denen ihr wirklich traut. Wo möglich, gewichtsbasierte Formate wie Safetensors bevorzugen und Herkunft prüfen, statt beliebigen Lade-Code mitlaufen zu lassen.

Nichts davon ist Panikmodus. Es ist die gleiche Sorgfalt, die man bei jeder externen Abhängigkeit anlegt, nur angewandt auf einen Ort, den viele Teams bisher als reine Bezugsquelle und nicht als Angriffsfläche gesehen haben. Wer die Datenhoheit grundsätzlich systematisch angehen will, findet die Leitplanken im Beitrag zur digitalen Souveränität für KI-Teams.

Der Vorfall zeigt zweierlei auf einmal: dass die Lieferkette für offene KI dieselbe Aufmerksamkeit braucht wie jede andere Software-Lieferkette, und dass Angreifer inzwischen ganze Einbrüche an eine KI delegieren. Beides spricht nicht gegen offene Modelle. Es spricht dafür, sie so ernst zu nehmen wie den Rest der eigenen Infrastruktur.