TanStack espone CrowdSec, WeaselBiscuit conferma la crisi della supply chain npm

🛡️ Executive Summary

• Il compromesso TanStack di maggio ha permesso di sottrarre circa 170 repository privati CrowdSec tramite credenziali presenti sul laptop di un ex dipendente.
• WeaselBiscuit usa invece pacchetti npm creati direttamente dagli attaccanti e si attiva quando il modulo viene importato, non durante l’installazione.
• I due casi mostrano lo stesso collo di bottiglia: token GitHub, estensioni browser e credenziali trasformano la workstation dello sviluppatore in una supply chain aziendale.

La supply chain npm sta mostrando due facce dello stesso problema. CrowdSec ha ricostruito come la compromissione dei pacchetti TanStack dello scorso maggio abbia portato, undici giorni dopo, alla copia di circa 170 repository GitHub privati attraverso le credenziali presenti sul laptop di un dipendente appena uscito dall’azienda. In parallelo, una nuova campagna distribuisce WeaselBiscuit, stealer JavaScript nascosto in pacchetti npm che raccoglie dati dalle estensioni Chrome e può intercettare clipboard e tastiera. Non risultano collegamenti operativi tra le due campagne. Il punto comune è invece architetturale: installare o importare una dipendenza non espone più soltanto il progetto corrente, ma può consegnare all’attaccante le identità digitali con cui lo sviluppatore raggiunge repository, cloud, wallet e infrastrutture aziendali.

TanStack non si è fermato a npm: CrowdSec scopre il furto di 170 repository

Il rapporto finale pubblicato da CrowdSec il 18 settembre collega direttamente il proprio incidente alla compromissione TanStack del maggio 2026. L’11 maggio TeamPCP aveva inserito Mini Shai-Hulud in 42 pacchetti TanStack, producendo 84 versioni malevole attraverso una catena che sfruttava GitHub Actions, cache poisoning e token OIDC. Il 22 maggio, secondo la ricostruzione forense di CrowdSec e il successivo supporto di GitHub, credenziali ottenute dal computer di un dipendente che aveva appena lasciato l’azienda sono state utilizzate per scaricare circa 170 repository privati in poco meno di dieci minuti. L’account GitHub dell’ex dipendente era rimasto temporaneamente attivo per permettergli di completare alcune attività e sarebbe stato revocato soltanto il 25 maggio.

CrowdSec precisa che l’attaccante ha copiato codice ma non ha modificato repository, pipeline di build, infrastruttura o database. Il materiale è riemerso soltanto il 16 settembre su un forum, quasi quattro mesi dopo l’esfiltrazione, e conteneva anche gli indirizzi email di 83 utenti CrowdSec e dati relativi a 51 potenziali investitori del 2020. Il caso aggiunge quindi una conseguenza concreta a ciò che Matrice Digitale aveva già ricostruito quando Shai-Hulud aveva compromesso TanStack attraverso la supply chain npm: il payload non doveva necessariamente distruggere la macchina o cifrare dati. Bastava raggiungere un endpoint sul quale esistessero ancora credenziali valide.

Leggi anche: Shai-Hulud diventa crisi sistemica della supply chain npm tra GitHub, Grafana e TeamPCP

Il vero payload di Shai-Hulud erano le identità dello sviluppatore

CrowdSec ammette che il proprio errore non è stato soltanto tecnico. Il laptop dell’ex dipendente possedeva una relazione di fiducia ancora valida con GitHub e l’organizzazione non aveva revocato immediatamente l’accesso al momento dell’uscita. Il malware proveniente dalla compromissione TanStack ha trasformato quella finestra amministrativa in un breach differito: l’infezione è avvenuta nella supply chain, ma il valore è stato estratto attraverso token e identità persistenti. È precisamente il modello che Shai-Hulud ha continuato a perfezionare nei mesi successivi, arrivando a cercare segreti in 469 percorsi associati a cloud, CI/CD, wallet e strumenti AI.

La conseguenza per la sicurezza enterprise è importante. SBOM, firme e provenance permettono di verificare quale pacchetto viene distribuito, ma non possono revocare una credenziale già copiata dalla workstation. Nel caso TanStack, inoltre, le release compromesse erano state pubblicate attraverso il workflow legittimo con attestazioni valide: il controllo della provenienza certificava correttamente da dove arrivava il software, non che il contenuto della build fosse benigno. Il confine da proteggere diventa quindi l’intero percorso dipendenza → processo locale → token → repository, con revoca immediata degli accessi al cambio di ruolo e rotazione delle credenziali dopo qualsiasi sospetta esposizione developer.

WeaselBiscuit cambia il trigger: il malware parte quando il pacchetto viene importato

Il secondo caso mostra un problema complementare. WeaselBiscuit è stato individuato in un cluster di pacchetti npm pubblicati attraverso account e nomi apparentemente ordinari, tra cui @biz44/id10-client, @biz44/runtime-utils, process-mite e process-tailwind. Il database OSV documenta direttamente il comportamento malevolo di @biz44/id10-client: quando il modulo viene importato, avvia un processo Node.js separato, recupera codice da un endpoint Npoint e lo esegue, collegandosi poi all’infrastruttura dell’attaccante. Un secondo record OSV per process-tailwind descrive lo stesso schema, compreso l’uso di new Function() per eseguire il payload ricevuto dal dead drop.

La distinzione rispetto a molti attacchi npm recenti è decisiva: non serve un lifecycle script preinstall o postinstall. Il codice scatta quando l’applicazione carica il modulo. Questo significa che una policy come npm ci --ignore-scripts, utile contro le famiglie che abusano degli install hook, non blocca necessariamente questa catena. Una volta attivo, WeaselBiscuit raccoglie informazioni sull’host e scandisce lo storage locale delle estensioni Chrome su Windows, macOS e Linux; su Windows può inoltre ricevere comandi per catturare clipboard e battiture. OpenSourceMalware segnala sovrapposizioni funzionali con BeaverTail e OtterCookie, famiglie associate alla campagna nordcoreana Contagious Interview, ma questa somiglianza non dimostra da sola che gli stessi operatori abbiano gestito WeaselBiscuit.

Chrome diventa il deposito da saccheggiare perché le estensioni contengono stato e segreti

WeaselBiscuit è più leggero di BeaverTail e OtterCookie: non incorpora una RAT completa, non dispone delle stesse funzioni di persistenza e non integra direttamente un wallet drainer. Il targeting dello storage delle estensioni Chrome resta però economicamente significativo perché directory come Local Extension Settings possono contenere stato applicativo, configurazioni e informazioni riconducibili a wallet, strumenti developer o altre estensioni sensibili. Il malware non deve necessariamente conoscere in anticipo quale estensione interessa all’attaccante: può prelevare il contenuto leggibile e lasciare la selezione al backend. È un modello coerente con ciò che la campagna Contagious Interview sta facendo da anni contro gli sviluppatori. Repository, coding challenge e moduli Node.js sono efficaci perché l’esecuzione di codice di terze parti rientra nella routine professionale della vittima. Matrice Digitale aveva già documentato BeaverTail e OtterCookie dentro repository utilizzati nei falsi colloqui, dove il bersaglio reale non era soltanto il PC ma i token GitHub, le chiavi SSH, le configurazioni AWS e i wallet presenti nello stesso ambiente di sviluppo.

Il collegamento tra le due notizie quindi non è l’attribuzione. Non ci sono elementi per collegare WeaselBiscuit all’attore che ha compromesso TanStack o CrowdSec. Ciò che coincide è il modello economico: la workstation dello sviluppatore vale perché concentra accessi che appartengono a sistemi diversi. Una dipendenza compromessa può diventare il ponte verso GitHub; un modulo malevolo apparentemente minore può trasformare il browser in una fonte di dati finanziari e credenziali.

Continua con:
Estensioni e coding assistant diventano vettori d’attacco tra BragJack e Shai-Hulud
Falsi colloqui LinkedIn, ACN avverte l’Italia tre anni dopo Matrice Digitale

La difesa npm deve proteggere la credenziale dopo l’esecuzione, non solo il pacchetto prima

I due incidenti rendono insufficiente una strategia concentrata esclusivamente sulla reputazione della dipendenza. TanStack dimostra che anche pacchetti ufficiali e provenance valida possono diventare vettori quando la pipeline di pubblicazione viene compromessa; WeaselBiscuit dimostra che bloccare gli install script non basta quando il codice malevolo viene eseguito all’import. La difesa deve quindi spostarsi anche sull’endpoint: token GitHub a vita breve, credenziali cloud con scope minimo, account aziendali revocati immediatamente all’offboarding, wallet separati dalla workstation di sviluppo e browser profile distinti possono limitare ciò che un singolo modulo riesce a trasformare in accesso persistente. Il punto più importante è che la dipendenza npm non è più necessariamente il bersaglio finale né il malware il prodotto finale dell’attacco. È il mezzo con cui raggiungere identità che permettono di attraversare repository, CI/CD e servizi cloud. CrowdSec scopre mesi dopo che una compromissione TanStack aveva già raggiunto il proprio codice privato; WeaselBiscuit mostra contemporaneamente quanto poco codice serva per estrarre valore da un browser developer. La superficie della supply chain si è quindi spostata: dal pacchetto al dispositivo che lo esegue e, soprattutto, a tutte le relazioni di fiducia che quel dispositivo porta con sé.