L’attacco supply chain che ha colpito NPM il 15 settembre 2025 segna un salto di pericolosità: una campagna di phishing mirato contro maintainer ha consentito di pubblicare versioni infette di pacchetti molto diffusi, mentre un worm auto-propagante, battezzato Shai-Hulud, ha moltiplicato la superficie di compromissione con velocità inedita. Le analisi di Trend Micro e di altri team confermano l’uso di hook post-install, offuscamento e catene di esfiltrazione per rubare credenziali e dirottare wallet crypto, con telemetrie che indicano impatti in Nord America ed Europa. Il parallelismo con l’attacco a Nx di fine agosto 2025 evidenzia tattiche ricorrenti contro maintainer high-profile. Le organizzazioni devono reagire immediatamente con pin delle dipendenze, blocco degli update automatici, rotazione token e audit dei repository; in parallelo, serve un rafforzamento strutturale di SBOM, code signing, segregazione della CI/CD e controllo degli egress di rete per impedire payload secondari come Cryptohijacker. Le prime indagini confermano centinaia di pacchetti coinvolti e la natura wormable del codice ostile, aspetto che impone monitoraggio continuo e piani di risposta coordinati tra team di sviluppo e SecOps.
Cosa leggere
Cos’è successo il 15 settembre 2025 e perché conta?
Il 15 settembre un ingegnere ha segnalato su canali pubblici una compromissione in corso del registro NPM. Poche ore dopo, più analisi indipendenti hanno documentato un’ondata di pacchetti manomessi, con stime che sono rapidamente passate da alcune decine a oltre 180 elementi e poi a circa 200 progetti infetti. Tra i nomi spuntano librerie popolari come @ctrl/tinycolor e pacchetti mantenuti da vendor di sicurezza, un segnale forte dell’ampiezza della superficie colpita. La campagna non si è limitata all’inserimento di malware: il componente worm ha sfruttato automatismi dell’ecosistema per diffondersi in modo self-replicating, trasformando un attacco di credenziali rubate in un evento di contagio a catena. In parallelo, ricercatori hanno tracciato il primo pacchetto malevolo noto pubblicato la sera del 14 settembre (rxnt-authentication), elemento utile per ricostruire la timeline.
La catena di attacco: dal phishing al worm auto-propagante
Il vettore iniziale è una campagna di phishing molto credibile contro maintainer noti. I messaggi imitavano comunicazioni di supporto npmjs, inducendo i destinatari ad “aggiornare” la 2FA o a rinnovare token di pubblicazione. In almeno un caso di alto profilo, il maintainer ha confermato pubblicamente di essere caduto nella trappola, consentendo agli attaccanti di spingere versioni infette a distanza di minuti l’una dall’altra. Una volta ottenuto l’accesso, il gruppo ha inserito codice ostile in release minori e patch apparentemente innocue, affidando la propagazione a meccanismi automatici e alla fiducia implicita nel registry. L’aspetto di novità è la componente Shai-Hulud, descritta dai ricercatori come il primo worm supply-chain per NPM: sfrutta dipendenze contaminate per insinuarsi nelle pipeline, e in alcune varianti abusa di routine e GitHub Actions per “seminare” compromissioni su progetti che consumano i pacchetti già infetti.
Tecniche d’iniezione e payload osservati
Il codice malevolo impiega hook post-install e script offuscati (spesso codificati in base64) per scaricare payload secondari da domini controllati dall’attaccante. La logica è opportunistica: su ambienti di sviluppo e build agent cerca artefatti sensibili (SSH keys, token NPM/GitHub, file .env e keystore), mentre su applicazioni che trattano cripto-asset tenta il dirottamento degli indirizzi o l’estrazione di seed e wallet. Alcune famiglie di campagna hanno mostrato un Cryptohijacker focalizzato sull’intercettazione di API web e sostituzione delle destinazioni di pagamento, con persistenza anche dopo riavvio e tendenza a “ripulire” i log. Le telemetrie iniziali posizionano le prime ondate in Nord America, con rapida estensione a paesi europei; l’assenza di tracce certe del verme Shai-Hulud in certe fasi non ha escluso la sua presenza in altre, data la natura modulare della campagna.
Cosa distingue Shai-Hulud dagli attacchi NPM del passato
A differenza delle infezioni “monolitiche” viste storicamente, Shai-Hulud viene descritto come un malware wormable capace di auto-replicarsi all’interno della supply chain: non attende che gli sviluppatori installino manualmente la versione infetta, ma innesca meccanismi di infezione secondaria su repository che consumano i pacchetti compromessi. In più report tecnici la campagna è definita “prima nel suo genere” per la capacità di sfruttare automatismi di ecosistema e pipeline di integrazione continua, arrivando in alcuni casi a compromettere il flusso di pubblicazione di progetti terzi. Questo spiega l’accelerazione dal primo cluster di poche decine di pacchetti alle centinaia censite nei giorni successivi.
Parallelismi con l’attacco a Nx di fine agosto
Molti indicatori tattici richiamano l’attacco Nx del 27–29 agosto 2025: spear-phishing su maintainer, esecuzione condizionata a OS non Windows per eludere difese, interesse spiccato per token e segreti di sviluppo e un focus esplicito su asset crypto. Alcuni osservatori attribuiscono ai medesimi attori la firma operativa, segnalando perfino l’uso strumentale di tool AI da riga di comando per ricognizione ed esfiltrazione. La differenza sostanziale è che l’attacco Nx ha colpito una suite di tool di build, mentre il nuovo evento ha investito librerie core dell’ecosistema JavaScript, ampliando di conseguenza il bacino d’utenza a rischio.
Confronto sintetico: NPM di settembre vs Nx di agosto
L’attacco colpisce al cuore la fiducia nel codice aperto. Le aziende che dipendono da NPM per build e deploy vedono interrotti i flussi per via di allarmi antimalware, checksum che non tornano, o peggio esecuzione di payload in ambienti dev e CI/CD. I rischi concreti vanno dall’esfiltrazione di credenziali cloud e token VCS al dirottamento di pagamenti cripto; in taluni cluster, la conta delle librerie compromesse ha superato rapidamente le 180 unità, includendo componenti con milioni di download settimanali, un ordine di grandezza capace di propagare danni in pochi minuti. Proprio la presenza di librerie di formattazione, utility e color nel set colpito aggrava il quadro, perché moltiplica i consumatori indiretti.
Indicatori e segnali da cercare subito
I team SecOps e Platform dovrebbero verificare la presenza di versioni pubblicate tra il 14 e il 16 settembre con script post-install inattesi, codice offuscato, chiamate HTTP/HTTPS a domini mai visti, e file temporanei sospetti creati in fase di installazione. È cruciale controllare la storicizzazione dei token npm e le IP di emissione, cercare commit anomali nei repository mirrorati dagli autori compromessi e incrociare hash di tarball con feed d’IOC condivisi dalla comunità. Laddove si tratti di wallet o componenti che interfacciano crypto, conviene rivedere log di rete e audit trail delle API in cerca di sostituzione di indirizzi o chiamate non autorizzate; i detentori di credenziali rubate vanno ruotati subito.
Mitigazioni immediate (0–72 ore)
La priorità è fermare la propagazione. Il primo passo è bloccare gli update automatici, pinnare le versioni note e ricostruire gli ambienti da lockfile verificate. Occorre disabilitare l’esecuzione di post-install in scenari di rischio, o perlomeno ispezionarli rigorosamente prima di consentirne l’uso. La rotazione di tutti i token NPM/GitHub e delle chiavi SSH è obbligatoria per i maintainer coinvolti e per i consumatori che hanno costruito da macchine potenzialmente compromesse; allo stesso tempo, va sospeso ogni deploy da agent sospetti e introdotte policy egress restrittive sugli host di build per impedire download di payload secondari. L’EDR su build server e developer workstation dovrebbe cercare comportamenti come rundll32 anomalo su Windows, curl/wget in fasi di install non previste e tentativi di credential dumping.
Rafforzamento strutturale
Una volta contenuto l’incidente, conviene stabilire guardrail permanenti. La produzione di SBOM aggiornate per ogni release consente di mappare rapidamente quali versioni contengono pacchetti a rischio; l’integrazione di SCA nel CI/CD con blocco hard-fail su versioni segnalate impedisce la reintroduzione di dipendenze infette. L’adozione di 2FA ovunque sia possibile resta fondamentale, ma l’episodio dimostra che può essere aggirata in fase di publish se la piattaforma lo consente: servono quindi token scoped, scadenze brevi, approvazioni a quattro occhi per release critiche e, quando disponibile, provenance e firma delle build. L’isolamento di CI sensibili in VPC dedicati con egress allow-list riduce drasticamente la probabilità di C2 riusciti.
Perché l’ecosistema JavaScript è così esposto
L’ecosistema JavaScript favorisce composizione e riuso spinto: micro-librerie con poche righe di codice finiscono in milioni di progetti. Questo è un punto di forza per l’innovazione, ma diventa un punto di fragilità quando un attore acquisisce la possibilità di pubblicare versioni infette. La presenza di hook in fase di installazione, pensata per compiti legittimi, offre un canale per scaricare malware. Con Shai-Hulud, l’avversario ha dimostrato che la scalabilità della supply chain può essere sfruttata non solo per distribuire un payload, ma per propagarlo con logiche wormable, sfruttando dipendenze transitive e automazioni di sviluppo.
Lezioni apprese dal caso Nx
Il caso Nx ha mostrato come l’esecuzione condizionata e l’attenzione selettiva a Linux e macOS possano eludere controlli tipici in ambienti Windows-centrici. Ha inoltre evidenziato la corsa degli avversari a impiegare perfino assistenti AI CLI per scrivere, offuscare e orchestrare il furto di segreti. La ripetizione di pattern simili in settembre indica che il fattore umano del maintainer rimane il punto di leva preferito; di conseguenza, oltre ai controlli tecnici, servono processi di verifica per i maintainer e triage rapido delle notifiche sospette che imitano i messaggi di piattaforma.
Governance e responsabilità condivisa
Il registro NPM, i maintainer e i consumatori condividono responsabilità. I registry devono rafforzare rilevazioni comportamentali su publish atipici, introdurre frizioni sane per release ad ampia superficie e migliorare la telemetria disponibile ai proprietari dei pacchetti. I maintainer devono adottare igiene delle credenziali, separare dispositivi personali e di build, e limitare i permessi di pubblicazione. I consumatori, infine, devono trattare la supply chain come codice non fidato: monitorare, validare, isolare. La difesa più efficace nasce dal presupposto che una compromissione sia sempre possibile, e che l’obiettivo sia rilevarla e confinarla prima che diventi sistemica.
Domande chiave per i CISO nelle prossime 48 ore
I CISO dovrebbero chiedere ai team: quali versioni sono state installate tra il 14 e il 16 settembre? Esistono log di post-install imprevisti? Che token sono stati esposti tramite build agent? Quali host hanno contattato domini anomali? Le policy egress dei runner impediscono download non autorizzati? È stato attivato un blocco temporaneo per release provenienti da maintainer citati nelle advisory? Le risposte a queste domande determinano la finestra reale di esposizione e i passi successivi per il recovery.
Evoluzione probabile nelle prossime settimane
È plausibile l’emersione di varianti del worm, magari con loader meno rumorosi o con tecniche di persistenza più efficaci in CI. Ci si può attendere la weaponization di nuove catene che puntano a firmware developer o a estensioni di editor popolari per ottenere privilegi di pubblicazione. La comunità sta già consolidando indicatori condivisi, retro-analizzando diff sospetti e rimuovendo versioni compromesse; ma la riapertura è possibile finché esisteranno credenziali non ruotate o pipeline non ringfence.
Anatomia di una kill chain “wormable” su NPM
Una kill chain coerente con i dati pubblici inizia con spear-phishing su un maintainer. L’avversario ottiene token di publish e introduce una minor release con post-install offuscato. Alla prima npm install, lo script contatta un C2, scarica un dropper che rileva ambiente e, se su dev box o runner CI, raccoglie SSH, token e .env. Il dropper tenta l’inoculazione su progetti che consumano la libreria tramite commit automatizzati o abuso di GitHub Actions, caratteristica che conferisce al malware la qualità wormable descritta in più analisi. Una volta rubate credenziali con privilegi, l’avversario scala verso pacchetti più diffusi, ribaltando la fiducia transitiva della supply chain. La mitigazione richiede spezzare l’anello in più punti: validazione pre-publish del maintainer, approvazioni e firma per release sensibili, blocco degli script post-install in ambienti poveri, egress allow-list, SCA in CI e telemetria correlata tra registry, VCS e endpoint. Il merito di Shai-Hulud non è la sofisticazione del singolo payload, ma l’orchestrazione dell’ecosistema per ottenere scala e persistence fuori misura rispetto allo sforzo iniziale.
