Nuova ondata di attacchi colpisce centinaia di pacchetti npm

L’ecosistema npm è finito nuovamente nel mirino degli attaccanti.

Secondo un’analisi di SafeDep, 314 pacchetti risultano infetti in quella che i ricercatori hanno denominato campagna “Mini Shai-Hulud”, un riferimento al comportamento auto-propagante del malware all’interno della supply chain JavaScript.

L’incidente riaccende i riflettori sulla sicurezza di uno dei repository più utilizzati al mondo per la distribuzione di librerie Node.js, con milioni di download quotidiani e integrazioni dirette nei pipeline CI/CD aziendali. Il pattern di attacco sfrutta meccanismi consolidati, ma con una capacità di diffusione orizzontale che lo rende particolarmente insidioso.

Come funziona l’attacco e come si propaga

Il punto di ingresso più comune è il furto di credenziali di pubblicazione, ottenuto tramite phishing o esposizione accidentale di token nei repository pubblici. Una volta preso il controllo di un pacchetto legittimo, il codice malevolo viene inserito nelle fasi di installazione, in particolare negli hook preinstall e postinstall, meccanismi nativi di npm pensati per automazioni legittime ma facilmente abusabili per eseguire comandi non autorizzati sui sistemi degli sviluppatori o direttamente nei pipeline di build.

L’elemento distintivo della campagna Mini Shai-Hulud è la capacità del malware di enumerare le dipendenze correlate e tentare la propagazione verso altri pacchetti mantenuti dallo stesso account o organizzazione, espandendo rapidamente la superficie di attacco e complicando il contenimento.

Gli script analizzati da SafeDep utilizzano payload offuscati in JavaScript puro, con tecniche di encoding Base64 e funzioni dinamiche come eval per mascherare l’esecuzione reale. Durante l’installazione, il codice accede a variabili sensibili presenti nell’ambiente, inclusi token npm, chiavi API e configurazioni CI, per esfiltrarle verso endpoint controllati dagli attaccanti.

Perché npm è strutturalmente vulnerabile

In un ecosistema basato su dipendenze interdipendenti, anche una compromissione limitata produce effetti a catena difficili da arginare. I pipeline CI/CD sono i più esposti: installano dipendenze automaticamente durante la build, spesso con privilegi elevati e senza verifiche approfondite sugli script eseguiti.

A questo si aggiunge la frammentazione della supply chain JavaScript, composta in larga parte da librerie di piccole dimensioni mantenute da singoli sviluppatori, una superficie ampia e difficile da monitorare in modo centralizzato.

Le contromisure efficaci agiscono su tre livelli. La prevenzione richiede autenticazione a più fattori per gli account npm e la riduzione dei token a lungo termine nei sistemi di pubblicazione automatica.

Il rilevamento dipende da strumenti capaci di analizzare gli script di installazione prima dell’esecuzione, individuando pattern sospetti come richieste HTTP non documentate o codice offuscato. Il contenimento, infine, si gioca sulla velocità di identificazione e revoca delle versioni infette: nel caso di attacchi propagativi come questo, ogni ora di ritardo amplia il raggio d’azione lungo le catene di dipendenze.

Tempistiche di risposta e lezioni strutturali

L’incidente conferma una vulnerabilità strutturale della supply chain open source: la fiducia tra maintainer, repository e consumatori non è sufficiente senza verifiche automatiche robuste e controlli di sicurezza continui.

La velocità di risposta rimane il fattore più critico, ma la prevenzione a monte, attraverso standard di pubblicazione più stringenti e audit obbligatori sulle versioni recenti, è l’unica leva in grado di ridurre significativamente la frequenza di questi episodi.