Il ritorno di Shai-Hulud: il worm ChainDrop colpisce npm, infettando centinaia di pacchetti

Il 4 agosto 2026, un hacker ha preso il controllo dell’account GitHub del manutentore di keyv, una libreria di caching chiave-valore con circa centinaia di milioni di download settimanali su npm, e ha iniettato un worm per il furto di credenziali nell’intera famiglia di pacchetti del manutentore, tra cui cacheable, flat-cache, file-entry-cache e cache-manager. Denominato ChainDrop, il worm si è diffuso in centinaia di altri pacchetti con oltre due miliardi di installazioni mensili complessive.

Ciò che rende la situazione pericolosa non è il numero di download, ma il modo in cui il codice dannoso è riuscito a guadagnarsi la fiducia degli utenti. L’autore dell’attacco ha pubblicato il codice tramite la pipeline di rilascio automatizzata del progetto stesso, quindi le versioni compromesse presentavano una provenienza valida: la prova firmata che un pacchetto fosse stato compilato dalla pipeline ufficiale a partire dal codice sorgente originale. Tale prova dovrebbe costituire un segnale di sicurezza. In questo caso era autentica, poiché la pipeline stessa era stata compromessa. Agli occhi di uno sviluppatore, o di uno strumento di sicurezza che verificasse la firma, la versione dannosa appariva del tutto autentica.

ChainDrop rappresenta l'ultima ondata di una campagna che i ricercatori stanno monitorando dal settembre 2025: Shai-Hulud 1.0 (settembre 2025), 2.0 (novembre 2025) e Mini Shai-Hulud, Quarta Ondata (maggio 2026). Ciascuna di queste varianti ha registrato un'escalation, con quelle successive caratterizzate da una propagazione più aggressiva e da exploit più estesi nella catena di approvvigionamento.

• Data: “keyv@6.0.0” è il titolo confermato, pubblicato il 4 agosto 2026.

• Punto di ingresso: l'attacco è iniziato con la compromissione dell'account GitHub di un responsabile della manutenzione, e la versione dannosa è stata distribuita attraverso la normale pipeline di pubblicazione del progetto.

• Entità: i dati variano a seconda del tool di monitoraggio, ma tutti i rapporti concordano sul fatto che si sia trattato di un incidente di enorme portata nella catena di approvvigionamento di npm. StepSecurity ha segnalato inizialmente 435 pacchetti e 1.557 versioni, mentre Aikido e rapporti successivi hanno portato il totale a livelli più elevati, con alcune stime che superano i 1.300 pacchetti e circa 2 miliardi di download mensili.

• Payload: Esiste un percorso di preinstallazione che utilizza il file setup.mjs, il quale scarica Bun e avvia un payload di grandi dimensioni, offuscato, finalizzato al furto di credenziali.

• Attribuzione: i ricercatori lo classificano nella famiglia di malware Shai-Hulud.

Ciò che rende ChainDrop particolarmente preoccupante è che non si è avvalso di un exploit appariscente né di un sito di download fasullo. Ha invece sfruttato la normale catena di fornitura del software, ovvero lo stesso processo di pubblicazione e installazione dei pacchetti utilizzato da milioni di sviluppatori.

In pratica, ciò significa che un pacchetto può apparire legittimo pur contenendo di nascosto codice dannoso che si attiva durante l'installazione. I team di sicurezza affermano che il malware è stato progettato per sottrarre informazioni riservate dai computer degli sviluppatori e dai sistemi CI/CD, tra cui token GitHub, credenziali npm, chiavi AWS, segreti Kubernetes e altri dati di accesso.

Il rischio più ampio non si limita agli sviluppatori. Qualsiasi organizzazione che utilizzi i pacchetti interessati può subire indirettamente la compromissione attraverso i sistemi di compilazione, le dipendenze e le pipeline di rilascio automatizzate.

ChainDrop ci ricorda che le dipendenze open source rappresentano un rischio aziendale, non solo una preoccupazione per gli sviluppatori.

Per qualsiasi organizzazione che si affidi a JavaScript e a Node.js, ChainDrop ci ricorda che le dipendenze open source rappresentano un rischio aziendale, non solo una preoccupazione per gli sviluppatori.

Un pacchetto compromesso può essere ereditato indirettamente attraverso le dipendenze e i sistemi di compilazione, e può portare al furto di credenziali, all’accesso non autorizzato all’infrastruttura cloud, nonché alla rotazione delle chiavi segrete su larga scala e alla gestione degli incidenti. Laddove l’integrità del software, il controllo degli accessi e il rischio legato a terze parti rientrano nel vostro ambiente di controllo, come previsto da PCI DSS, DORA, NIS2 e CMMC, tale esposizione ricade direttamente anche sulla conformità e sulla governance.

Se avete installato un pacchetto interessato a partire dal 4 agosto 2026:

• Analizza le tue dipendenze: genera un SBOM e verifica le dipendenze rispetto alle versioni note come dannose

• Acquisisci un'immagine prima della revoca: acquisisci un'immagine dei sistemi interessati prima di effettuare la rotazione dei token. Il malware monitora la revoca delle credenziali e può attivare un handler se si procede prima alla rotazione.

• Rotazione delle credenziali esposte: effettuare la rotazione di tutte le credenziali accessibili (token npm, PAT di GitHub, chiavi SSH, credenziali cloud) e rendere obbligatoria l'autenticazione a più fattori (MFA)

• Verifica in base alla versione esatta, non al nome: effettua la corrispondenza in base alla versione esatta risolta, non al nome del pacchetto; i tag del registro sono stati modificati durante l'incidente

• Rimuovi gli hook a livello di repository: controlla i file .claude/settings.json e .vscode/tasks.json, non solo node_modules

• Audit CI/CD: eseguire un audit su CI/CD e GitHub Actions per individuare pubblicazioni impreviste o nuovi flussi di lavoro

La lezione da trarre è che la difesa efficace contro questo tipo di attacchi consiste nel verificare il contenuto di un componente, anziché fidarsi della sua provenienza.