← Tutti gli articoli
Il worm che ha infettato keyv: dentro l'attacco alla supply chain npm di agosto

Il worm che ha infettato keyv: dentro l'attacco alla supply chain npm di agosto

2 min di lettura

Il 4 agosto è stato compromesso l'account GitHub del manutentore di keyv, 127 milioni di download a settimana, e in due giorni un worm auto-propagante ha avvelenato oltre 1.300 versioni di pacchetti. Non serve usare keyv per essere colpiti. Cosa abbiamo controllato sulle pipeline dei clienti.

Il 4 agosto 2026 un attaccante ha preso il controllo dell'account GitHub del manutentore di keyv, una libreria di storage chiave-valore con circa 127 milioni di download settimanali su npm, e da lì ha iniettato un worm che ruba credenziali nell'intera famiglia di pacchetti. Il 6 agosto i ricercatori contavano oltre 1.300 versioni compromesse, per un totale combinato di due miliardi di download al mese. Se avete un progetto Node, il problema non è se usate keyv: è se una delle vostre dipendenze lo tira dentro senza che ve ne accorgiate.

Come funziona la catena

Le release malevole contengono una variante Mini Shai-Hulud, ribattezzata CHAINDROP: un payload JavaScript pesantemente offuscato, costruito su Bun, che si esegue in automatico attraverso un hook preinstall del ciclo di vita npm, prima ancora che l'installazione del pacchetto si completi. Il worm cerca token npm, credenziali GitHub e chiavi cloud sulla macchina, li esfiltra e, se trova un token con permessi di pubblicazione, ripubblica sé stesso su altri pacchetti. È così che da keyv è arrivato a cacheable, flat-cache e file-entry-cache, dipendenze che quasi nessuno installa di proposito ma che finiscono nell'albero di mezzo ecosistema.

Perché la PMI viene colpita per rimbalzo

Nessuno dei nostri clienti dipende da keyv direttamente. Ci arrivano tutti per via transitiva, attraverso strumenti di build, framework di test e librerie di caching. Un npm install lanciato sul portatile di uno sviluppatore o su un runner di CI il 5 agosto è bastato a eseguire il payload con le credenziali di quella macchina. L'attacco non bussa alla porta principale, entra dalla catena delle dipendenze.

Cosa abbiamo controllato, in quest'ordine

  • Le date di installazione: qualunque npm install o npm ci tra il 4 e il 6 agosto va trattato come sospetto finché non è provato il contrario, sul portatile come sul runner.
  • Le credenziali sulle macchine esposte: rotazione immediata dei token npm e GitHub, e delle chiavi cloud presenti sui runner che hanno buildato in quella finestra. Un worm che ruba token si ferma solo revocandoli.
  • Il lockfile contro il registry: verificare che le versioni risolte non siano quelle avvelenate, e ricostruire l'albero da un lockfile pulito.
  • Gli script in fase di installazione: in CI, npm ci --ignore-scripts disinnesca l'intera classe di attacco preinstall. Dove serve uno script legittimo, lo si esegue esplicitamente, non per magia del gestore pacchetti.

Verdetto

Il vero bersaglio di questi attacchi non è il vostro codice, sono le credenziali degli sviluppatori e i token di CI. La difesa strutturale è smettere di trattare npm install come un comando innocuo: disattivate gli script del ciclo di vita in automatico, fidatevi del lockfile e non del tag latest, e tenete i token con permessi di pubblicazione fuori dalle macchine di sviluppo. Shai-Hulud tornerà con un altro nome il mese prossimo, la superficie di attacco è sempre la stessa.