Pluto Security berichtete am 29. Oktober 2026 von einer zweiten Welle mit Schadsoftware in Modell-Repositories auf Hugging Face. Nachdem Konten der ersten Welle entfernt worden waren, tauchten binnen weniger Tage neue Repositories auf, so die technische Analyse von Pluto Security. Am selben Tag berichtete BleepingComputer, eine am 25. Oktober hochgeladene Kopie namens htt0118/qwen2-tiny bei eigener Prüfung als mit demselben Miner und einer Reverse Shell versehen bestätigt zu haben.
Was die Downloadzahlen zählen
Bis zum 28. Oktober zählte Pluto Security 31 Kern-Repositories in sieben Hugging-Face-Konten sowie 13 zusätzliche, verknüpfte Modelle. Die insgesamt 32.376 Downloads sind keine Zahl bestätigter Infektionen oder einzelner Nutzer.
| Gruppe | Repositories | Downloads | Bezugszeitraum |
| Erste Welle | 12 | 728 | Vor der Entfernung |
| Zweite Welle | 19 | 29.090 | Stand: 28. Oktober 2026 |
| Verknüpfte Modelle | 13 | 2.558 | Stand: 28. Oktober 2026 |
| Kern-Repositories und verknüpfte Modelle zusammen | 44 | 32.376 | Gesamtsumme laut Pluto Security, Stand: 28. Oktober 2026 |
Die 44 umfassen 31 Kern-Repositories plus 13 verknüpfte Modelle. Pluto Security erfasste für die erste Welle 728 Downloads vor der Entfernung; für die zweite Welle und die verknüpften Modelle nannte das Unternehmen jeweils den Stand vom 28. Oktober.
Wie Python-Code beim Laden eines Modells ausgeführt wurde
Der zentrale Schalter war trust_remote_code=True. Wenn er aktiviert war, konnte der Loader Python-Code aus dem Modell-Repository importieren. Python führt Anweisungen auf Modulebene bereits beim Import aus, also während des Ladens und mit den Rechten des ladenden Prozesses.
Beim untersuchten Repository MENXIANGYU/qwen2-tiny war die Datei model.safetensors laut Pluto Security 42 Byte groß und enthielt keine Tensoren. Der Schadcode lag stattdessen in der Python-Datei modeling_evil2.py. Damit lag der beschriebene Ausführungsweg im Repository-Code, nicht in manipulierten Modellgewichten.
Welche Spuren und Varianten Pluto Security beschrieb
In einem untersuchten Build startete der Miner syscore.bin aus dem Arbeitsspeicher und tarnte sich mit dem Prozessnamen [kworker/u20:1]. Ein Überwachungsprozess unter /tmp/.cch/svc.py startete den Miner alle 120 Sekunden neu, wenn er fehlte. Hinzu kamen Änderungen an Shell-Startdateien. Pluto Security nennt diese Pfade und den Prozessnamen als Ansatzpunkte für eine Untersuchung.
Einige Varianten richteten außerdem Reverse Shells ein, also Verbindungen, über die ein Betreiber aus der Ferne eine Shell erreichen kann. Pluto Security ordnete dieses Verhalten den Builds qwen2-tiny-5, qwen2-tiny-6 und qwen2-tiny-9 zu; sie verbanden sich mit 212.32.253.3 über Port 443 oder 9443. Das galt nicht pauschal für alle Repositories. Als separates späteres Skript beschrieb Pluto Security MENXIANGYU/qa-whl-1021: Es konnte aus einem privilegierten Container mögliche Festplatten des Host-Systems einbinden und Root-Zugriff auf den Host herstellen.
Für die Suche auf einem betroffenen System nennt Pluto Security neben /tmp/.cch/, svc.py und Shell-Startdateien auch den getarnten Prozess mit Mining-Argumenten. In Xinference können kodierte Modellregistrierungen mit den Präfixen qwen2-tiny- oder ezv- ein weiterer Hinweis sein. Die Untersuchung kann zudem Verbindungen zu der von Pluto Security aufgeführten Infrastruktur einbeziehen. Das Fehlen eines einzelnen Indikators schließt einen Befall nicht aus.
Was Teams nach dem Laden eines verdächtigen Modells tun sollten
Pluto Security empfiehlt, einen Rechner auch dann zu untersuchen, wenn das Laden fehlgeschlagen ist oder die GPU-Auslastung normal aussieht. Die beschriebenen Modelle zielten auf selbst gehostete Inferenzumgebungen wie Xinference und GPUStack, gemietete GPU-Rechner, gemeinsam genutzte Forschungsnotebooks und CI-Jobs, die Testmodelle abrufen.
- System isolieren und Belege zu Prozessen, Netzwerkverbindungen, Protokollen, Modell-Cache und Startdateien sichern.
- Weitere Systeme prüfen, auf denen dieselben Repositories geladen wurden, und nach den genannten Prozess-, Datei-, Start- und Netzwerkspuren suchen.
- Persistenz und Hintertüren entfernen, nicht nur den sichtbaren Miner.
- Erreichbare Zugangsdaten von einem sauberen System aus ändern.
- Das System aus einem vertrauenswürdigen Abbild neu aufsetzen, wenn sich seine Integrität nicht feststellen lässt.
