Worm npm 'Mini Shai-Hulud': colpiti Mistral, TanStack, UiPath

Una nuova ondata del worm "Mini Shai-Hulud" ha investito l'ecosistema npm: il 12 maggio 2026 i ricercatori di sicurezza di Aikido hanno contato 373 versioni di pacchetto malevole distribuite su 169 nomi di pacchetto. Tra i progetti toccati ci sono nomi molto popolari fra gli sviluppatori - vari pacchetti dell'ecosistema TanStack (incluso react-router), strumenti di UiPath, librerie come Squawk - e pacchetti riconducibili a Mistral AI. E' l'evoluzione di una campagna che ad aprile aveva preso di mira i pacchetti npm di SAP, e che ora si e' allargata.

Da dove arriva il nome e cosa c'era prima

"Shai-Hulud" e' il nome dei vermi giganti del deserto nel romanzo Dune: i ricercatori lo hanno usato a settembre 2025 per un primo worm che si propagava fra i pacchetti npm rubando segreti. La variante "Mini" e' una versione piu' compatta dello stesso schema, ricomparsa ad aprile 2026 contro i pacchetti SAP e poi mutata nella campagna di maggio. E' la dimostrazione di un problema strutturale: l'ecosistema npm e' un grafo gigantesco di dipendenze, e basta compromettere alcune librerie molto usate per raggiungerne a cascata moltissime altre.

Come funziona l'attacco, in concreto

Secondo l'analisi di Aikido, il meccanismo e' questo:

• Il pacchetto compromesso include un file offuscato (router_init.js) e aggiunge una optional dependency ospitata su GitHub.
• Durante l'installazione (npm install), npm esegue gli script del ciclo di vita anche per le dipendenze prese da Git: un prepare hook apparentemente innocuo lancia cosi' il payload.
• Il codice malevolo gira soprattutto dentro i sistemi di integrazione continua (CI/CD), dove cerca e ruba token GitHub, credenziali npm, chiavi AWS, token Kubernetes, accessi a Vault.
• Con quelle credenziali, il worm pubblica nuove versioni infette di altri pacchetti, propagandosi da solo - da qui il termine "worm".

L'obiettivo finale non e' tanto colpire l'utente finale di un'app, quanto impossessarsi delle "chiavi del regno" dei team di sviluppo: una volta dentro la pipeline, l'attaccante puo' avvelenare il software a monte.

Cosa c'entra l'intelligenza artificiale

Il punto che rende questa storia rilevante per chi segue l'IA e' duplice. Primo: gli SDK ufficiali di molti laboratori - tra cui appunto Mistral - sono distribuiti proprio via npm, e finiscono dentro applicazioni che usano modelli linguistici in produzione. Un pacchetto compromesso puo' quindi diventare la porta d'ingresso verso le chiavi API dei provider di IA, con costi e rischi di abuso enormi. Secondo: gli assistenti di coding basati su IA (da Claude Code a Cursor) installano e aggiornano dipendenze in modo semi-automatico, spesso senza che lo sviluppatore controlli ogni singola versione - un comportamento comodo che, in un contesto del genere, amplifica la superficie d'attacco.

Cosa fare se hai usato uno dei pacchetti colpiti

Le raccomandazioni dei ricercatori sono nette:

1. Cercare nei propri package-lock.json / yarn.lock i pacchetti e le versioni indicati negli avvisi (Aikido, Sophos, Wiz e Unit 42 hanno pubblicato gli elenchi).
2. Trattare come potenzialmente compromessa qualsiasi macchina o runner CI/CD che abbia eseguito l'installazione, finche' i segreti non sono stati ruotati.
3. Ruotare immediatamente token npm, personal access token GitHub, chiavi cloud, credenziali di deploy e qualsiasi API key (incluse quelle dei provider di IA) presenti in quegli ambienti.
4. Verificare l'attivita' di pubblicazione recente sui propri pacchetti npm e attivare, dove possibile, il trusted publishing e l'autenticazione a piu' fattori.

npm, dal canto suo, ha rimosso le versioni malevole man mano che venivano segnalate, ma data la natura auto-propagante del worm e' probabile che nuove varianti continuino a comparire nei prossimi giorni. Il consiglio di fondo resta lo stesso che gli esperti ripetono da mesi: bloccare le versioni delle dipendenze, evitare l'esecuzione automatica degli script di installazione quando non serve, e trattare la pipeline di build come un ambiente sensibile quanto la produzione.

Perche' attacchi cosi' continuano a riuscire

Il problema non e' un bug puntuale, ma il modello stesso con cui funziona il software moderno. Un'applicazione JavaScript media tira dentro centinaia, a volte migliaia, di pacchetti transitivi: dipendenze di dipendenze di dipendenze, scritte e mantenute da volontari sparsi per il mondo, spesso da una sola persona. Basta che a quella persona venga rubato un token - tramite phishing, tramite una pipeline compromessa, tramite un altro pacchetto infetto - e ogni progetto che dipende dal suo lavoro e' a rischio. Gli script di installazione (postinstall, prepare) peggiorano le cose: sono pensati per compilare codice nativo o preparare l'ambiente, ma di fatto eseguono codice arbitrario sulla macchina di chi installa, compresi i server di build aziendali che hanno in mano le chiavi di tutto.

Negli ultimi due anni la frequenza di queste campagne e' aumentata: dal grande compromesso npm del settembre 2025 in poi, le ondate si sono susseguite quasi ogni mese, con bersagli sempre piu' "di valore" - pacchetti scaricati milioni di volte a settimana, SDK di aziende note, strumenti di automazione. Il fatto che fra i nomi ci siano ora anche librerie legate all'IA conferma che gli attaccanti seguono il denaro: dove ci sono chiavi API costose e infrastrutture cloud generose, c'e' un incentivo a colpire.

Cosa possono fare i team, oltre all'emergenza

Al di la' della rotazione dei segreti dopo un incidente, gli esperti suggeriscono alcune abitudini "di igiene": usare lockfile e installare con comandi che rispettano esattamente le versioni bloccate (npm ci invece di npm install in CI); disabilitare gli script di ciclo di vita quando non servono (npm install --ignore-scripts) e abilitarli solo per i pacchetti che davvero ne hanno bisogno; usare token a vita breve e con permessi minimi nelle pipeline; attivare la pubblicazione "fidata" (trusted publishing) e l'autenticazione a piu' fattori sugli account npm; e tenere d'occhio i feed di sicurezza - CISA, i blog di Aikido, Sophos, Wiz, Socket - perche' in queste vicende la velocita' di reazione conta piu' di tutto.