Il nuovo attacco supply-chain Shai Hulud: The Second Coming segna uno dei momenti più critici per l’ecosistema npm, con un worm auto-replicante che compromette 492 pacchetti, raggiungendo 132 milioni di download mensili e colpendo infrastrutture ad alta esposizione come le automazioni Zapier e l’identità decentralizzata ENS Domains. L’incidente rivela la fragilità dell’intero ecosistema JavaScript, già duramente provato da compromissioni precedenti, e mostra come i maintainer compromessi, la legacy authentication e i postinstall script possano trasformarsi in vettori di diffusione rapida e silenziosa. L’attacco ruba segreti, token, API key e credenziali, li carica su repository GitHub pubblici e tenta di propagarsi su altri pacchetti npm, dimostrando una capacità offensiva strutturata e una conoscenza profonda delle pipeline CI/CD moderne. Il coinvolgimento di pacchetti essenziali per automazioni cloud e per la gestione delle identità blockchain amplifica i rischi, mentre la risposta della community si concentra su rotazione dei segreti, blocco dei postinstall e attivazione della MFA, evidenziando una necessità ormai urgente di un modello di sicurezza applicato alla supply chain.
Cosa leggere
Una minaccia pervasiva nell’ecosistema npm
L’attacco Shai Hulud: The Second Coming sfrutta lo stesso principio della prima ondata, ma con una scalabilità enormemente superiore. Gli attaccanti pubblicano pacchetti compromessi su npm inserendo uno script postinstall in grado di attivare un processo multi-fase. Alla prima esecuzione, il pacchetto avvia setup_bun.js, che installa il runtime Bun se non presente. Una volta preparato l’ambiente, viene eseguito bun_environment.js, un payload offuscato che contiene il vero worm. Il codice opera in memoria per evitare detection tradizionali e avvia una scansione completa dell’ambiente di sviluppo e delle pipeline utilizzando strumenti come TruffleHog. Il worm individua token, API key e credenziali sparse nell’ambiente e le invia automaticamente su repository GitHub pubblici generati ad hoc, con descrizioni invariabili che riportano il nome “Sha1-Hulud: The Second Coming”.
Il worm non si limita al furto di segreti, ma tenta di auto-replicarsi pubblicando copie modificate su fino a cento altri pacchetti npm, sfruttando token compromessi o credenziali intercettate. Nei casi in cui l’autenticazione fallisce, il malware attiva un meccanismo distruttivo eliminando i file della home directory, un comportamento che evidenzia la volontà di massimizzare l’impatto anche in condizioni di fallback.
Il ruolo dei maintainer compromessi
L’incidente mette in luce un punto sensibile: per alcuni pacchetti di alto profilo, come quelli di AsyncAPI, è stato individuato un commit malevolo diretto, suggerendo un accesso ottenuto tramite breach dell’account del maintainer. Questo dettaglio indica che la compromissione non è avvenuta solo tramite automazione o furto generico di credenziali, ma include intrusioni mirate verso singoli sviluppatori, rendendo la minaccia più complessa della media degli attacchi supply-chain. Errori degli attaccanti, come la mancanza di file necessari in alcuni pacchetti, hanno limitato la diffusione totale del worm, ma senza ridurre la gravità complessiva dell’incidente.
L’impatto su Zapier e sul Web3 di ENS Domains
I pacchetti di Zapier, in particolare zapier-sdk e ai-actions, rappresentano un vettore di rischio critico perché integrati in workflow che automatizzano migliaia di servizi cloud. La compromissione di questi pacchetti può condurre a furti massivi di credenziali, spostamenti laterali nelle pipeline CI/CD e esposizione di ambienti di produzione. Il rischio non riguarda solo gli sviluppatori, ma anche aziende che costruiscono automazioni a catena su servizi esterni, creando un effetto domino complesso da controllare. Per ENS Domains, la compromissione di pacchetti come ensjs, ui ed ens-contracts colpisce la gestione delle identità decentralizzate basate su Ethereum. Questo settore vive sulla fiducia crittografica e sull’integrità del codice. Un attacco supply-chain in questo ambito può avere conseguenze profonde, compresi furti di nomi a dominio ENS, esposizione di wallet o vulnerabilità nelle interazioni tra componenti smart contract e applicazioni Web3. Il danno reputazionale rischia di essere enorme, perché la compromissione mina la fiducia verso l’intero modello di identità decentralizzata.
Tecniche di propagazione del worm e impatto complessivo
Il worm utilizza una sequenza di tecniche che combinano script postinstall, esecuzione fileless e pubblicazione automatica su GitHub. Il comportamento presenta caratteristiche simili a precedenti attacchi come S1ngularity, ma con un’evoluzione evidente. L’uso di Bun rappresenta un dettaglio tecnico peculiare: il runtime viene installato automaticamente come prerequisito per l’esecuzione del payload, consentendo agli attaccanti di evitare dipendenze dirette o controlli integrati in Node.js. L’entità dell’impatto è documentata da numeri rilevanti: 492 pacchetti compromessi, 132 milioni di download mensili, 26.3 mila repository privati e pubblici esposti tramite esfiltrazione delle credenziali. La compromissione simultanea di progetti come PostHog, Postman, AsyncAPI e gli ecosistemi di Zapier ed ENS Domains conferma che il bersaglio dell’attacco non è casuale ma orientato verso infrastrutture ad alto valore e ampia diffusione.
La legacy authentication come punto debole
È significativo che l’attacco avvenga poco prima della revoca da parte di npm dei token classici, prevista il 9 dicembre 2025. I vecchi token offrono superfici di attacco più ampie e sono meno granulari. La finestra temporale sfruttata dagli attaccanti suggerisce un’azione strategica per sfruttare al massimo le debolezze residue prima del passaggio obbligato ai token granulari. Questa evidenza alimenta l’ipotesi che il gruppo responsabile abbia una comprensione profonda delle dinamiche interne dell’ecosistema npm e delle abitudini dei maintainer.
Rischi per infrastrutture cloud e CI/CD
Il worm di Shai Hulud non si limita a colpire macchine locali, ma compromette le pipeline CI/CD, dove i segreti sono spesso presenti in variabili di ambiente o file temporanei. L’esfiltrazione di API key cloud, token GitHub, credenziali di automazione e password dei servizi interni può scatenare una catena di compromissioni. Le aziende sono costrette ad attivare rotazioni immediate dei segreti, a monitorare repository pubblici creati in modo sospetto e a implementare controlli su tutte le pipeline di build, aumentando i costi e la complessità della gestione emergenziale.
Confronto con attacchi precedenti
L’evoluzione rispetto alla prima ondata di Shai Hulud mostra un incremento quantitativo e qualitativo del modello di attacco. La prima ondata colpì venti pacchetti, mentre la seconda attacca contemporaneamente centinaia di componenti, generando un’esposizione su larga scala senza precedenti. La tattica rimane coerente: un worm auto-replicante che sfrutta la distribuzione massiva dell’ecosistema npm per moltiplicarsi. Tuttavia la seconda ondata introduce nuovi elementi come il fallback distruttivo, il coinvolgimento mirato di maintainer compromessi e una maggiore aggressività nella ricerca e pubblicazione dei segreti.
Implicazioni per il futuro della supply chain JavaScript
L’attacco Shai Hulud evidenzia un punto fondamentale: la supply chain JavaScript è intrinsecamente vulnerabile, basata su un ecosistema ad altissima fiducia in cui migliaia di sviluppatori installano automaticamente dipendenze senza verifiche manuali. Il modello del postinstall è particolarmente delicato, poiché consente ai pacchetti di eseguire codice arbitrario durante l’installazione. Un singolo punto di compromissione può propagarsi a milioni di dispositivi, ambienti cloud e workstation aziendali. La risposta della community è ormai chiara: rotazione dei segreti, attivazione obbligatoria della MFA, disabilitazione degli script postinstall nelle pipeline CI/CD, auditing approfondito delle dipendenze e utilizzo di strumenti come Safe-Chain per bloccare pacchetti malevoli a livello di registry. Tuttavia la vera questione riguarda la necessità di una trasformazione più profonda nella modalità di pubblicazione, manutenzione e verifica dei pacchetti npm.
