ChainDrop: l’attacco npm che ha compromesso 1.300 pacchetti e colpito 2 miliardi di download mensili
L'attacco ChainDrop ha infettato 1.300 pacchetti npm e 2 miliardi di download. Scopri come funziona il worm, cosa ruba e l'impatto sulla supply chain.
Immagine illustrativa generata con AI
Il 4 agosto 2026 è stata resa pubblica la campagna ChainDrop, un attacco supply-chain auto-propagante che ha infettato oltre 1.300 pacchetti npm e raggiunto un volume di download mensili stimato in circa 2 miliardi. L’operazione, ancora in evoluzione, è partita dalla compromissione dell’account GitHub del maintainer di Keyv e si è diffusa a cascata attraverso dipendenze condivise. I ricercatori di Aikido, Wiz, StepSecurity, Socket e Ox Security stanno monitorando l’espansione e pubblicando indicatori di compromissione.
L’innesco: l’account GitHub di Keyv e la catena di caching
L’attaccante ha preso il controllo dell’account GitHub del manutentore di Keyv, un diffuso modulo per la gestione di store chiave-valore. Da lì ha inserito codice malevolo direttamente sui branch principali di Keyv e dei pacchetti che ne discendono: Cacheable, flat-cache e file-entry-cache. Per rendere le nuove release credibili, l’aggressore ha sfruttato gli stessi GitHub Actions legittimi configurati nei repository. Il risultato è che ogni versione infetta pubblicata su npm conserva un’attestazione di provenienza valida, eludendo i controlli di molti strumenti di verifica della supply chain.
Il meccanismo di infezione: preinstall, Bun e il payload offuscato
Ogni pacchetto compromesso include un file setup.mjs richiamato dalla chiave preinstall nel package.json. Questo script viene eseguito automaticamente quando qualcuno lancia npm install. Il dropper scarica il runtime Bun e lo utilizza per eseguire un secondo file, Math_Symbol.js (o math_init.js), offuscato e contenente un infostealer con capacità di auto-diffusione.
Il worm non richiede interazione: basta installare una dipendenza infetta per far scattare l’intera catena. L’esecuzione avviene sul runner che effettua l’installazione, sia esso una workstation di sviluppo, un ambiente CI/CD o un container temporaneo.
Cosa ruba e come si propaga
L’infostealer raccoglie in modo aggressivo ogni credenziale raggiungibile dall’ambiente di esecuzione:
- token GitHub (
ghp_,gho_,ghs_), token npm (npm_) e segreti GitHub Actions; - credenziali AWS, compresi valori ottenuti da SSM con
WithDecryption: truee segreti da Secrets Manager; - segreti Kubernetes, token HashiCorp Vault, stringhe di connessione database;
- chiavi Stripe, Slack, Twilio, Azure, GCP e l’intero ambiente di processo.
Tutti i dati rubati vengono cifrati e inviati a un repository GitHub pubblico controllato dall’attaccante. Secondo Wiz è attivo anche il dominio npm-cache[.]com per l’esfiltrazione. Il worm non si limita a rubare: per ogni token ottenuto esegue una chiamata a registry.npmjs[.]org/-/whoami e, se il token risulta valido, lo usa per infettare nuovi pacchetti del maintainer corrispondente. La propagazione si autoalimenta, allargando il raggio a ogni installazione.
Impatto: compromissione totale di ambienti di sviluppo e CI/CD
Qualsiasi macchina che abbia eseguito npm install su una versione infetta deve essere considerata completamente compromessa, anche qualora il pacchetto venga successivamente rimosso. Il furto di credenziali cloud, segreti CI/CD e chiavi private apre a movimento laterale, esfiltrazione massiva e modifica non autorizzata di codice su repository di aziende come Deliveroo, Ornikar, OneReach, Picsart, Qlik e ServiceTitan, già impattate dalla campagna.
La presenza di provenance valida rende particolarmente insidioso l’attacco: molti strumenti di controllo, basandosi sulla corrispondenza tra attestazioni e sorgenti, non hanno rilevato anomalie prima che le prime analisi forensi portassero alla luce il meccanismo.
Come difendersi e ripartire
Le società di sicurezza coinvolte hanno diffuso liste di hash e domini malevoli, ma la priorità per le organizzazioni potenzialmente esposte è la reazione immediata:
- Ricostruire da zero gli ambienti compromessi o ripristinare backup non infetti.
- Ruotare tutti i token e le credenziali accessibili dall’ambiente impattato (GitHub PAT, token npm, chiavi AWS/GCP/Azure, segreti Vault, credenziali di database e di servizi esterni).
- Esaminare attentamente log di sistema e commit nei repository per individuare accessi anomali o modifiche non autorizzate.
- Applicare allowlist delle dipendenze e rivedere le policy di esecuzione degli script di
preinstall. - Monitorare in tempo reale gli indicatori di compromissione condivisi da Aikido, Wiz, StepSecurity, Socket e Ox Security.
La campagna ChainDrop è ancora attiva e il numero di pacchetti infetti continua a salire. Chi gestisce ambienti npm deve aspettarsi nuovi aggiornamenti e prepararsi a verificare l’integrità delle proprie dipendenze anche al di là delle prime liste di IoC.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.




