Per ben tre volte in otto mesi, lo stesso schema di attacco di un worm npm ha funzionato. Attaccanti diversi, pacchetti diversi, la stessa meccanica e lo stesso intervallo di tempo tra la pubblicazione e il rilevamento che ha reso possibile ogni attacco. Se vi state chiedendo cos'è effettivamente un worm npm e perché questo schema continua a ripetersi invece di essere corretto, ecco la risposta onesta: incidenti, meccanismi e l'unica falla che persino un solido sistema di difesa lascia aperta.
Cos'è un worm npm?
Un worm npm è un frammento di codice dannoso pubblicato sul registro npm che, una volta eseguito, si diffonde automaticamente ad altri pacchetti, in genere rubando le credenziali di pubblicazione di un manutentore e utilizzandole per iniettare lo stesso payload in ogni pacchetto controllato da quel manutentore. È un "worm" nel senso classico del termine: non aspetta che qualcuno lo installi deliberatamente, si propaga da solo, da pacchetto a pacchetto, da account ad account, alla velocità della macchina.
È proprio questa capacità di auto-propagazione a distinguere un worm npm da un normale pacchetto dannoso. Un singolo pacchetto malevolo è come un ago in un pagliaio. Un worm npm trasforma ogni manutentore compromesso in un nuovo punto di distribuzione, e il pagliaio inizia a generare i propri aghi.
I più grandi incidenti con worm npm finora
Nell'ultimo anno, il pattern npm worm è stato sottoposto a tre test sul campo, ognuno più efficiente del precedente:
- Shai-Hulud (settembre 2025). Il primo worm npm auto-propagante documentato. Ha compromesso le credenziali dei manutentori, utilizzandole poi per pubblicare versioni dannose di ogni pacchetto sotto il loro controllo, trasformando gli sviluppatori stessi nel meccanismo di diffusione per la fase successiva del worm.
- axios (marzo 2026). Malware di uno stato nazionale nascosto all'interno di un pacchetto scaricato circa 100 milioni di volte a settimana. Non un worm nel senso stretto del termine, ma la prova che lo stesso modello di fiducia dell'ecosistema npm sfruttato da Shai-Hulud può veicolare un payload su scala davvero massiccia.
- SAP npm (aprile 2026). Descritto all'epoca come un mini Shai-Hulud: lo stesso schema a verme, ripetuto su vasta scala, meno di un anno dopo l'incidente originale. Il meccanismo non era cambiato. Nemmeno le difese, per la maggior parte.
Tre incidenti con worm npm, uno schema ripetitivo: compromettere un editore fidato, utilizzare le sue credenziali per propagare automaticamente e contare sul lasso di tempo tra la pubblicazione e il rilevamento da parte della comunità per fare il resto.
Lo schema che si ripete
Eliminando i dettagli specifici, ogni incidente legato ai worm di npm segue sempre gli stessi quattro punti chiave:
- Compromissione dell'account. Un token di pubblicazione del manutentore, npm loginoppure le credenziali CI vengono rubate, di solito tramite phishing, una fuga di notizie riservate o una dipendenza compromessa più in alto nella loro catena.
- Iniezione silenziosa. L'attaccante distribuisce una nuova versione di un pacchetto legittimo e affidabile con l'aggiunta di codice dannoso, spesso all'interno di uno script di postinstallazione o di un altro script del ciclo di vita che viene eseguito automaticamente nel momento in cui qualcuno installa il pacchetto.
- Propagazione automatica. Se il manutentore compromesso controlla altri pacchetti, o se lo script dannoso stesso raccoglie ulteriori credenziali, il worm si diffonde al pacchetto successivo e al manutentore successivo senza ulteriori azioni da parte dell'attaccante.
- Il ritardo di rilevamento. Il pacchetto rimane attivo nel registro di sistema, installabile da chiunque, finché qualcuno non se ne accorge, lo segnala e viene rimosso. Questo lasso di tempo, che in alcuni casi può durare ore, in altri giorni, è l'intero lasso di tempo di cui il worm ha bisogno.
È fondamentale riconoscere che il quarto battito è ciò che conta davvero per la difesa. Ogni strategia di mitigazione per un incidente causato da un worm npm è, nella sua essenza, un tentativo di ridurre o aggirare quel ritardo di rilevamento.
Un framework degno di nota: la risposta di SIP al problema del cooldown.
Non tutte le risposte a questo schema provengono da un fornitore. Una delle più chiare è SIP, il Piano di Sicurezza Immediato di Mohammad-Ali A'râbi, un quadro di controllo di emergenza a cinque livelli per la gestione del rischio nella catena di fornitura del software, nato da una domanda molto pratica posta al termine di una sessione di SafeDev: "Se possiamo fare solo poche cose, cosa dovremmo fare per prima?"
Il secondo controllo di SIP è mirato direttamente al problema del worm npm: congelare le dipendenze non verificate con un periodo di raffreddamento di cinque giorni e disabilitare gli script del ciclo di vita in modo che un postinstall dannoso non possa essere eseguito automaticamente durante l'installazione. In pratica, questo significa min-release-age=5 and ignore-scripts=true in un progetto .npmrc, applicato in CI in modo che un file di blocco non possa risolvere silenziosamente un pacchetto pubblicato ieri. È un controllo davvero valido e che richiede poco sforzo, e mira direttamente allo stesso ritardo di rilevamento da cui dipende ogni incidente di worm npm. Approfondisci:
Dove la finestra di raffreddamento lascia ancora un vuoto
Il periodo di attesa è una scommessa: che la community si accorga e segnali un pacchetto dannoso prima della scadenza del periodo di attesa. Nella maggior parte dei casi, questa scommessa si rivela vincente. Una quota significativa di pacchetti compromessi viene segnalata entro i primi giorni dalla pubblicazione, ed è proprio per questo che un intervallo di cinque giorni rappresenta un valore predefinito ragionevole.
Ma un worm npm non si comporta come un tipico pacchetto dannoso, e questo cambia ciò che un cooldown fisso può e non può fare per te.
Per essere precise sulla velocità: Un worm a rapida propagazione non elude di per sé il cooldown. Se si impone un'età minima di rilascio rigorosa, i pacchetti pubblicati durante la prima ondata sono ancora troppo recenti per essere inclusi in una build, indipendentemente da quanti pacchetti il worm comprometta nel frattempo. La velocità è importante, ma lo è per tutti coloro che a valle non hanno un cooldown attivo, non per aggirarne uno già in vigore.
Il vero limite è la pazienza. Un payload più attento può rimanere inattivo oltre il periodo di raffreddamento, attivandosi solo dopo che i giorni sono trascorsi e il pacchetto è entrato nella zona "attendibile", precisSemplicemente perché sa che è in corso un periodo di ricarica. Questo è lo scenario in cui un periodo di ricarica fisso da solo non basta, ed è esattamente dove qualcosa come il rilevamento basato sulle prove di MEW deve affiancarlo, non sostituirlo.
Nessuna delle due modalità di errore rappresenta un difetto nella filosofia di SIP. Il periodo di attesa (cooldown) si basa sulla capacità di rilevamento da parte della community, e quest'ultima ha un limite: non può individuare ciò che nessuno ha ancora segnalato. Questa non è una lacuna esclusiva di SIP, bensì un limite strutturale di qualsiasi sistema di difesa che attenda l'esistenza di una firma, di un avviso o di una segnalazione pubblica prima di intervenire.
Come MEW colma il divario tra tempo di ricarica e tempo di recupero
Questo è preciscolmare il divario Malware Early Warning (MEW) di Xygeni È progettato per essere efficace. Invece di attendere segnalazioni dalla community o una firma pubblicata, MEW analizza continuamente NPM, PyPI e Maven man mano che vengono pubblicati nuovi pacchetti e versioni, analizzando il comportamento anziché confrontarlo con minacce note. Quando qualcosa sembra dannoso, viene messo in quarantena e la scoperta viene confermata dai ricercatori di sicurezza prima della divulgazione pubblica, non dopo.
Questa distinzione è importante per entrambe le modalità di fallimento del worm npm descritte sopra. Contro un worm a rapida propagazione, il rilevamento pre-firma non necessita dei cinque giorni di cooldown che un sistema di cooldown presuppone. Contro un payload paziente e dormiente, l'analisi comportamentale di MEW non cerca l'età o la reputazione, ma ciò che il codice effettivamente fa, quindi attendere la scadenza del cooldown non offre alcun vantaggio a un attaccante.
Il Dependency Firewall di MEW estende questo concetto fino al punto dell'installazione stessa, bloccando un pacchetto dannoso in tempo reale anche se è sfuggito ai controlli precedenti, e lo stesso livello di rilevamento copre il CI/CD lato di un incidente worm npm: lo schema sblocca-ramo, inietta, blocca nuovamente che consente a un attaccante di spingere un malevolo commit e cancellare silenziosamente le proprie tracce, lasciando comunque una documentazione completa qualora l'operazione dovesse comunque avere luogo.
SIP e MEW rispondono alla stessa domanda, ma a livelli diversi.
Niente di tutto ciò rende errato il controllo del cooldown di SIP, ed è bene dirlo chiaramente: un cooldown di cinque giorni con gli script del ciclo di vita disabilitati è ancora una delle difese più rapide ed economiche che un team possa implementare contro un normale incidente di worm npm, e dovrebbe essere incluso in qualsiasi serio piano di rafforzamento della supply chain. Ciò che non può fare, per sua stessa natura, è individuare ciò che la community non ha ancora scoperto. Questo è compito del rilevamento continuo basato sul comportamento, che opera al di sotto del cooldown, non in sostituzione di esso.
Sovrapposti insieme, i due approcci coprono entrambe le estremità dello stesso problema: SIP rafforza la build pipeline, il blocco delle dipendenze e l'immagine del container attorno a un panorama di minacce noto e divulgato, mentre il rilevamento pre-firma di MEW copre gli incidenti del worm npm che non sono ancora stati divulgati, quelli che una finestra di cooldown, per sua stessa logica, non può prevedere.
FAQ
Cos'è un worm npm, in una sola frase?
Codice dannoso pubblicato su npm che si diffonde automaticamente ad altri pacchetti, in genere rubando le credenziali di un manutentore e utilizzandole per iniettare lo stesso payload altrove, senza ulteriore intervento da parte dell'attaccante.
Ogni pacchetto npm dannoso è un worm npm?
No. Un pacchetto dannoso che non si propaga autonomamente è un attacco alla catena di approvvigionamento, ma non un worm. Ciò che definisce specificamente un incidente di worm npm è la fase di autopropagazione: una compromissione che porta automaticamente alla successiva.
Un periodo di cooldown delle dipendenze blocca un worm npm?
Riduce significativamente il rischio, poiché la maggior parte dei pacchetti dannosi viene segnalata entro i primi giorni dalla pubblicazione. Tuttavia, un periodo di attesa (cooldown) si basa sulla velocità di rilevamento da parte della comunità, e un worm npm a rapida propagazione o deliberatamente inattivo può essere creato appositamente per eludere tale finestra temporale.
Cosa riesce effettivamente a catturare un worm npm prima che si attivi il periodo di raffreddamento?
Scansione continua basata sul comportamento, che non dipende dall'esistenza di una firma o di una segnalazione pubblica. È proprio questa lacuna che strumenti di rilevamento pre-firma come MEW di Xygeni si propongono di colmare.
