Campagna cryptomining su Hugging Face supera 32.000 download con 19 nuovi repository dopo takedown

Una campagna di cryptomining distribuita tramite repository malevoli su Hugging Face è tornata attiva pochi giorni dopo la rimozione iniziale, con 19 nuovi repository che hanno portato il totale a 31. Il meccanismo sfrutta trust_remote_code=True per eseguire codice Python sui server GPU delle vittime. L'operazione ha superato i 32.000 download totali, con un singolo modello che ha raggiunto 28.412 download al 28 ottobre 2026. Otto giorni dopo la segnalazione iniziale, alcuni repository erano ancora live.

Il meccanismo: auto_map prima dei pesi

Il nucleo tecnico dell'operazione risiede in una caratteristica documentata della libreria Transformers di Hugging Face. Quando un utente imposta trust_remote_code=True, il caricamento di un modello esegue il codice Python referenziato nel campo auto_map del file config.json tramite exec_module(), prima ancora di accedere ai pesi del modello.

Pluto Security ha verificato che i repository della campagna — spacciandosi per checkpoint Qwen2-tiny — contengono file modeling_evil.py di 305 righe nelle versioni iniziali, ridotte a 37 righe nelle varianti con backdoor SSH. Questi file non vengono analizzati dai sistemi di sicurezza della piattaforma, che si concentrano sui modelli serializzati e sugli exploit tradizionali come la deserializzazione pickle.

Il payload iniziale installa peakminer, un miner camuffato come processo kernel kworker/u20:1. Il binario di 40,6 MB è impacchettato con UPX ma con marker modificati — PEK! invece di UPX! — per evitare la decompressione automatica. Viene lanciato via memfd_create e fexecve, senza lasciare eseguibili su disco.

"reviewing the .py files an auto_map points to before the flag is set would have caught every payload in the campaign" — Pluto Security

32.376 download e un wallet di circa 5.000 dollari

La campagna principale ha raccolto 29.818 download, che salgono a 32.376 includendo repository collegati, secondo i conteggi di Pluto Security. Il modello più scaricato, MENXIANGYU/qwen2-tiny, ha raggiunto 28.412 download al 28 ottobre 2026 — il 97,7% dei download della seconda ondata — passando "scanned clean" nonostante il payload attivo. Il conteggio è passato da 7.354 del 20 ottobre a 28.412 del 28 ottobre, come documentato da screenshot verificati da BleepingComputer.

L'impatto economico è verificabile on-chain. Il wallet dell'operatore ha ricevuto circa 2.276 PRL, valutati intorno ai 5.000 dollari, con 716 transazioni nella prima ondata e circa 2.241 PRL inoltrati successivamente. Secondo Pluto Security, circa 2.237 dollari provengono da ricompense di 30 giorni sulla pool Kryptex, con attività continuata anche dopo la rimozione dei repository.

Pluto ha osservato nove macchine in un cluster GPU condiviso avviare simultaneamente il mining, fermate dopo circa sei minuti — probabilmente da un amministratore che ha killato i job. Questo conferma che le infezioni reali sono significativamente inferiori ai download: molti utenti non attivano trust_remote_code o scaricano senza eseguire.

La seconda ondata: container escape e persistenza rapida

La reazione dell'operatore al takedown è stata rapida. Entro pochi giorni dalla rimozione iniziale, sono apparsi 19 repository di seconda ondata. Il repository MENXIANGYU/qa-whl-1021, pubblicato 8,5 ore dopo la disclosure via email a Hugging Face, conteneva script di escape da container che montavano dischi host e puntavano a /var/lib/gpustack — indicando consapevolezza degli ambienti di deployment ML.

Un clone su account htt0118, creato il 25 ottobre, era ancora live al momento della verifica di BleepingComputer con lo stesso payload. Il dropper di seconda ondata risponde con static ip. e status 403 a richieste da IP non autorizzati, limitando l'analisi dinamica.

Le versioni successive della campagna hanno aggiunto una reverse shell verso server C2 su Alibaba Cloud (212.32.253.3:443/9443), espandendo la post-infezione da puro mining a accesso persistente remoto.

Perché i scanner non vedono nulla

Il buco cieco di sicurezza è strutturale. I controlli di Hugging Face impiegano ClamAV e scanner di modelli orientati ai pickle exploit, ma non analizzano il comportamento del codice Python referenziato da auto_map. JFrog, interpellato da Pluto sulla natura dei file, ha risposto che si tratta di "not a machine-learning model" — corretto sul formato, inutile sulla minaccia.

La documentazione ufficiale di Hugging Face ammette che gli scanner sono "not 100% foolproof". Pluto Security ha dimostrato che la revisione manuale dei file .py puntati da auto_map prima dell'impostazione del flag avrebbe intercettato ogni payload della campagna. Nessun sistema automatizzato equivalente è attualmente in produzione sulla piattaforma.

Pluto cita CVE-2026-22807 per vLLM come correlato: questa vulnerabilità permette di bypassare il flag trust_remote_code in specifiche condizioni di deployment, amplificando la superficie di attacco per campagne simili.

Cosa fare adesso

La sezione seguente riporta indicatori di compromissione documentati nel report Pluto Security, non raccomandazioni ufficiali della piattaforma.

Pluto Security ha identificato questi elementi nel report tecnico:

• Processi kworker/u20:1 con consumo anomalo di risorse in ambienti dove non è previsto un worker kernel con quel pattern
• Connessioni in uscita verso 212.32.253.3 sulle porte 443 o 9443
• File config.json con campo auto_map che referenzia moduli .py non standard per il modello dichiarato
• Binari lanciati via memfd_create senza corrispondente file su disco

Pluto Security ha constatato nel report che "reviewing the .py files an auto_map points to before the flag is set would have caught every payload in the campaign". Questa è un'osservazione retrospettiva sulle tecniche di rilevazione, non un'istruzione operativa diretta agli utenti.

Analisi: il pattern più ampio

Fatti verificati: La campagna documentata mostra un'evoluzione rapida dal mining puro al container escape, con tempi di reazione all'takedown misurati in ore. L'operatore ha mantenuto attività di mining profittevole per settimane, con guadagni tracciabili on-chain.

Analisi: La struttura di questa operazione — abuso di funzionalità legittime, mimetismo nei flussi di lavoro standard, monetizzazione immediata e ritorno post-takedown — rappresenta un modello replicabile su piattaforme di hosting modello che non verificano il codice di supporto. La dipendenza da trust_remote_code per modelli specializzati rende la disattivazione semplice impraticabile senza rottura di funzionalità legittime.

Limiti della verifica e fonti

L'analisi tecnica completa proviene dal report Pluto Security pubblicato su unite.ai. La verifica indipendente di BleepingComputer si limita al payload live del clone htt0118/qwen2-tiny, al conteggio download del modello principale, e alla conferma che il repository era ancora live dopo la segnalazione. L'attribution a operatore di lingua cinese, motivato finanziariamente, è basata su commenti in cinese semplificato, server C2 su Alibaba Cloud e orari di attività — indizi che Pluto presenta come assessment, non come prova definitiva.

Il numero di download non equivale a infezioni confermate: Pluto specifica esplicitamente che molti utenti scaricano senza attivare trust_remote_code.

Fonti

• unite.ai
• bleepingcomputer.com
• blog.netmanageit.com