Krypto-Miner und Backdoors in Hugging-Face-Modellen: Hunderte Downloads, Scanner blind

Pluto Security hat auf Hugging Face 31 bösartige Modell-Repositories entdeckt, die Kryptominer und Hintertüren auf Rechner schleusen. Der Trick: Beim Laden mit trust_remote_code=True läuft fremder Python-Code, die Gewichte sind harmlos. Die Betreiber kehrten nach der Löschung binnen Tagen zurück.

Sonstiges 29. Okt. 2026 5 Min. Lesezeit Quelle: Unite.AI
Symbolbild, KI-generiert

Worum es geht

Das Sicherheitsunternehmen Pluto Security hat am 29. Oktober 2026 seinen Bericht „Load/Mine“ veröffentlicht. Er beschreibt eine Kampagne, die über bösartige Modell-Repositories auf Hugging Face (einer großen Plattform zum Teilen von KI-Modellen) Kryptominer und Hintertüren verbreitet. Gezählt werden 31 bösartige Repositories auf sieben Hugging-Face-Konten plus eine Kopie auf ModelScope, einer chinesischen Modellplattform. Es gab 29.818 Downloads, 32.376 mit 13 verknüpften Repositories. Pluto betont: Das sind Downloads, keine bestätigten Infektionen oder eindeutigen Opfer. Die Berichte der anderen Quellen nennen wegen früherer Stichtage kleinere Zahlen (etwa 21.614 am 25. Oktober, 28 Repositories).

Wie der Angriff funktioniert

Die Angreifer manipulieren keine Modellgewichte. Sie nutzen ein dokumentiertes Verhalten der Transformers-Bibliothek: Wer ein Modell mit trust_remote_code=True lädt, erlaubt, dass Python-Code aus dem Repository ausgeführt wird. Die Datei config.json verweist per auto_map auf ein Python-Modul. Transformers lädt es herunter und führt dessen Code beim Import aus, noch bevor Gewichte geladen werden, mit den Rechten des aufrufenden Nutzers. Das ist keine Standardeinstellung, und die Sicherheitsrichtlinie von Transformers verlangt, die Modelldateien vorher zu prüfen. In einem Beispiel ist die Datei model.safetensors nur 42 Byte groß und enthält gar keine Tensoren.

Der Bericht verweist außerdem auf die Sicherheitslücke CVE-2026-22807: vLLM-Versionen von 0.10.1 bis vor 0.14.0 luden auto_map-Module, ohne die Einstellung trust_remote_code zu prüfen, sodass ein bösartiges Repository beim Serverstart Code ausführen konnte.

Entdeckung und Zuordnung

Pluto baute einen Scanner, der alle über auto_map referenzierten .py-Dateien sowie Python-Dateien neben Gewichten auf verdächtige Muster wie subprocess, socket, ctypes, memfd_create und base64-Dekodierung prüft. Der erste Treffer war dsxk4mr8tq/qwen2-tiny-gpt2 mit einer 305 Zeilen langen Datei modeling_evil.py. Der Account hatte sechs Repositories innerhalb von 2,5 Stunden am 12. Oktober 2026 angelegt.

Der Durchbruch kam durch vergessene Backup-Dateien: Ältere Versionen der Schadsoftware verwiesen auf die Konten hhzz667 (Hugging Face) und wssb123e (ModelScope). Der Betreiber hatte Produktivcode in ein Testkonto kopiert, die URLs angepasst und die Backups vergessen. Die erste Welle umfasste 12 Repositories auf drei Konten und zwei Plattformen, mit über 700 Downloads vor der Entfernung und ohne jede Sicherheitsmarkierung.

Die Schadsoftware

Am Beispiel MENXIANGYU/qwen2-tiny beschreibt der Bericht:

  • Ein Watchdog unter /tmp/.cch/svc.py startet den Miner alle 120 Sekunden neu; Startbefehle landen in /root/.bashrc, /root/.profile und der .bashrc des Nutzers.
  • Drei Varianten bauen eine Reverse Shell (Fernzugriff, bei dem das Opfer die Verbindung zum Angreifer aufbaut) zu 212.32.253.3 auf Port 443 oder 9443 auf.
  • Der Miner syscore.bin startet über memfd_create und fexecve direkt aus dem Speicher und tarnt sich als Kernel-Prozess kworker/u20:1; es liegt zunächst keine ausführbare Datei auf der Platte.
  • Die 40,6 MB große Datei ist mit UPX gepackt, wobei zwei Markierungen von „UPX!“ zu „PEK!“ verändert wurden, damit das Standardwerkzeug sie ablehnt. Pluto stellte sie wieder her und fand den Miner „peakminer“.
  • Statusmeldungen werden in die Modellregistrierung von Xinference (eine Software zum Betrieb von Modellen) geschrieben; Konkurrenz-Miner werden entfernt und beendet.
  • Eine Variante sucht GPU-Plattformen für LLaMA-Factory und sammelt Tencent-Cloud-Metadaten. Ein Skript (qa-whl-1021) versucht, aus einem Container auszubrechen und GPUStack-Verzeichnisse anzugreifen.

Zwei Wellen

Das Konto hhzz667 entstand am 29. April 2026 und blieb fünf Monate ruhig. Am 21. September 2026 erschien qwen2-shell, eine 37 Zeilen lange SSH-Hintertür mit einem ed25519-Schlüssel. Einen Tag später folgte qwen2-final, ein dateiloser Miner mit 305 Zeilen. Kommentare im Code sind auf vereinfachtem Chinesisch.

Nach Plutos Meldung wurden die Konten entfernt. Binnen Tagen kam die zweite Welle mit 19 Repositories auf fünf Konten, darunter MENXIANGYU (13 Repositories). Das Hauptrepository MENXIANGYU/qwen2-tiny wuchs von 7.354 Downloads am 20. Oktober auf 28.412 am 28. Oktober, also 97,7 Prozent der Downloads der zweiten Welle. Ein späterer Dropper liefert die zweite Stufe nur an bestimmte IP-Adressen aus.

Einnahmen und mögliche Opfer

Die Wallet der ersten Welle erhielt etwa 2.276 PRL über 716 Transaktionen, rund 5.000 Dollar, und war am 21. Oktober trotz entfernter Repositories noch aktiv. Neun Worker mit Notebook-typischen Namen traten innerhalb von 90 Sekunden bei und verschwanden etwa sechs Minuten später, was nach Plutos Deutung zu einem gemeinsamen GPU-Cluster passt. Eine separate Familie („hl“) brachte in einem Monat nur etwa 26 Dollar.

Scanner-Lücke

Hugging Face prüft laut Dokumentation jede Datei unter 2 GB bei jedem Commit mit ClamAV und Pickle-Scans, räumt aber ein, dass dies „nicht 100 % wasserdicht“ ist. Partnerscanner wie JFrog meldeten für die Nutzlast „safe“ oder „kein ML-Modell“. Pluto meint, ein Blick in die per auto_map referenzierten Dateien oder eine statische Upload-Prüfung auf subprocess, socket, ctypes oder rohe IP-Aufrufe hätte alle Nutzlasten gefunden.

Täterprofil

Pluto vermutet einen finanziell motivierten, chinesischsprachigen Täter oder eine kleine Gruppe: chinesische Kommentare, ein Command-and-Control-Server bei Alibaba Cloud, Spiegelung auf ModelScope und hf-mirror.com, Ausrichtung auf Xinference und Tencent Cloud sowie Aktivität zwischen 18:38 und 21:19 UTC. Ein Build mit indonesischen Kommentaren spricht für einen zweiten Betreiber oder gezielte Tarnung.

Was du tun solltest

Wer eines der betroffenen Modelle mit aktiviertem Custom Code geladen hat, sollte nach /tmp/.cch/, unerwarteten svc.py-Prozessen, einem kworker/u20:1-Prozess mit Mining-Argumenten, kodierten Xinference-Einträgen (qwen2-tiny- oder ezv-) und Verbindungen zu den genannten Servern suchen. Empfohlen: betroffene Rechner isolieren, Beweise sichern, alle Persistenzwege entfernen, Zugangsdaten von einem sauberen Rechner aus erneuern, bei Zweifeln neu aufsetzen, die Xinference-API absichern und geprüfte Modellrevisionen festpinnen. Das bloße Löschen des Miners oder Modells reicht nicht.

Einordnung

Der Fall zeigt, dass Modell-Repositories ein Weg für klassische Schadsoftware sind, ohne dass Gewichte manipuliert werden müssen. Die Verantwortung liegt laut Transformers beim Nutzer. Der Schaden (rund 5.000 Dollar Mining-Erlös) ist moderat, die Hintertüren und Reverse Shells sind aber gefährlich. Die Zahl der echten Opfer ist offen, die Quelle ist ein Bericht des Sicherheitsunternehmens selbst, und die Angaben schwanken je nach Stichtag.

Quellen

#sicherheit#hugging-face#malware#kryptomining#supply-chain
Originalquelle lesen

Frag den KI-Assistenten

Fragen zu diesem Artikel, zur Installation oder zu Hintergründen? Unser Assistent kennt diese Seite und läuft auf unserem eigenen Rechner, nicht in einer fremden Cloud.

Verbinde …

Der Assistent ist eine KI (Gemma 4) und kann sich irren – wichtige Angaben bitte in der Quelle prüfen. Fragen werden nur zum Beantworten genutzt und nach einer Stunde gelöscht. Bitte keine persönlichen Daten eingeben.

Kommentare

Was meinst du dazu? Schon ausprobiert? Schreib es hier, ohne Anmeldung.

  1. Kommentare werden geladen …

Kommentare sind öffentlich. Links sind nicht erlaubt, beleidigende Beiträge löschen wir. Deinen eigenen Kommentar kannst du in diesem Browser jederzeit wieder löschen. Mehr dazu in der Datenschutzerklärung.