Pluto meldde cryptomining via repositories op Hugging Face

Op 29 oktober 2026 meldde Pluto Security dat een malwarecampagne via modelrepositories op Hugging Face na verwijdering van accounts in een tweede golf was teruggekeerd. De code kon tijdens het laden van een model starten en cryptominingsoftware installeren. Pluto’s analyse beschreef 31 kernrepositories in twee golven; BleepingComputer meldde diezelfde dag dat het een kopie, geplaatst op 25 oktober, had onderzocht en daarin dezelfde miner en een reverse shell aantrof. Pluto Security beschreef de technische bevindingen en aanwijzingen voor onderzoek.

Wat de aantallen repositories en downloads betekenen

Pluto Security telde zeven accounts met samen 31 kernrepositories: 12 in de eerste golf en 19 in de tweede. Daarnaast volgde het bedrijf 13 gekoppelde modellen. Tot en met 28 oktober telde Pluto 32.376 downloads over de kernrepositories en gekoppelde modellen. Dat zijn downloadtellingen, geen aantallen bevestigde besmettingen of unieke gebruikers.

De 31 kernrepositories bestaan uit de 12 repositories van de eerste golf en de 19 van de tweede. De 13 gekoppelde modellen vormen een aparte groep. De totale downloadtelling omvat dus 44 repositories, maar zegt niet hoeveel systemen de code daadwerkelijk hebben uitgevoerd.

Hoe code al tijdens het laden kon draaien

Wanneer een modelrepository eigen Python-code gebruikt, kan de optie trust_remote_code=True ervoor zorgen dat Transformers de module importeert waarnaar de repositoryconfiguratie verwijst. Python voert code op moduleniveau uit tijdens die import, dus voordat de loader de modelklasse teruggeeft. Die code draait met de rechten van het proces dat het model laadt.

In MENXIANGYU/qwen2-tiny zat de schadelijke code volgens Pluto Security in modeling_evil2.py. Het bestand model.safetensors was volgens de analyse 42 bytes groot en bevatte geen tensors. De kwaadaardige activiteit zat dus in de repositorycode die tijdens het laden werd uitgevoerd, niet in de modelgewichten.

Welke sporen de malware achterliet

De beschreven varianten gebruikten verschillende technieken om de miner te starten, te verbergen of opnieuw op te starten. In een door Pluto onderzochte build werd de miner syscore.bin vanuit het geheugen gestart onder de procesnaam [kworker/u20:1]. Een watchdog in /tmp/.cch/svc.py kon een verdwenen miner elke 120 seconden opnieuw starten; shell-opstartscripts boden een extra manier om de code actief te houden.

Pluto noemde deze concrete aanwijzingen om op hosts te onderzoeken:

• De map /tmp/.cch/ en onverwachte activiteit van svc.py.
• Wijzigingen in shell-opstartscripts en een proces met de naam [kworker/u20:1] met miningargumenten.
• Gecodeerde registraties met qwen2-tiny- of ezv- in Xinference.
• Netwerkverbindingen met infrastructuur die met de campagne werd geassocieerd.

Sommige varianten bevatten ook een reverse shell, waarmee een externe partij opnieuw verbinding kon maken. Pluto koppelde dit specifiek aan qwen2-tiny-5, qwen2-tiny-6 en qwen2-tiny-9; deze builds verbonden met 212.32.253.3 via poort 443 of 9443. Pluto beschreef daarnaast MENXIANGYU/qa-whl-1021 als een afzonderlijk script dat vanuit een geprivilegieerde container kandidaat-schijven van de host kon koppelen en toegang op rootniveau op die host kon verkrijgen.

Wat teams na het laden van een verdacht model kunnen doen

Pluto Security adviseerde een host te onderzoeken wanneer die een verdacht model had geladen, ook als het laden mislukte of het GPU-gebruik normaal leek. Het ontbreken van één genoemde aanwijzing sluit volgens Pluto een besmetting niet uit. De aanbevolen respons verloopt als volgt:

1. Isoleer de host en bewaar bewijs van processen, netwerkverbindingen, logs, cachebestanden en opstartgedrag.
2. Controleer andere systemen waarop dezelfde repositories zijn geladen en onderzoek de genoemde bestanden, processen, registraties en verbindingen.
3. Verwijder de persistentie en eventuele backdoors, niet alleen de zichtbare miner.
4. Vernieuw inloggegevens vanaf een schoon systeem als de besmette processen die gegevens konden bereiken.
5. Bouw de host opnieuw op vanaf een vertrouwde image als de integriteit van het systeem niet kan worden vastgesteld.