Npm, un worm noto da 111 giorni elude il malware scanning del registry

Il 7 settembre 2026, il payload worm npm conosciuto come Shai-Hulud è riapparso sul registry con lo stesso identico SHA-256 documentato quattro mesi prima. L'evento ha bypassato il sistema di publish-time malware scanning che npm aveva introdotto a luglio 2026, trattenendo i pacchetti 5-15 minuti per analisi automatica. Il ritorno dopo 111 giorni di inattività non è una novità tecnica: è un test di regressione involontario che il sistema di sicurezza del registry ha fallito sul caso più elementare possibile.

111 giorni di silenzio, poi il match esatto

Aikido ha registrato 319 versioni di pacchetto con l'hash Shai-Hulud il 19 maggio 2026, durante la campagna che ha compromesso 639 versioni dello scope @antv in un'ora. Tra il 20 maggio e il 6 settembre 2026, zero rilevazioni. Poi, il 7 settembre, quattro nuove versioni con lo stesso identico SHA-256.

Il periodo di dormienza è il più lungo documentato per questo payload. "That's 111 days of complete silence on that hash. As far as we can tell, that's the longest dormancy-to-reactivation gap we've seen from a Shai-Hulud payload, and it's not close", ha scritto il team di ricerca Aikido. La ripubblicazione non ha coinvolto repacking, offuscamento o modifica del codice: si tratta di un match esatto di un artifact noto e indicizzato.

I quattro pacchetti ripubblicati — feishu-docx-mcp@0.3.2, bmc-i18n-extract-cli@1.1.1, blueai-cli@0.7.0, bmc-translate-utils@1.1.1 — sono stati tutti pubblicati nella stessa ora del 7 settembre dallo stesso account npm, secondo la fonte. Il dominio di comando e controllo, t[.]m-kosche[.]com, era già presente nella campagna di maggio.

Il meccanismo di auto-propagazione

Il worm opera attraverso un ciclo chiuso di download, infezione e ripubblicazione. Il preinstall script esegue bun run index.js immediatamente all'installazione. Il payload ruba i token npm dalla macchina compromessa, li valida contro il registry, enumera i pacchetti associati all'account con permessi di pubblicazione, inietta il proprio codice, incrementa la versione e ripubblica automaticamente.

La persistenza è garantita attraverso file creati in .vscode/tasks.json e .claude/settings.json, che sopravvivono alla rimozione del pacchetto originale e permettono al malware di mantenere il controllo anche dopo che il codice sorgente infetto è stato eliminato dalla directory node_modules. La fonte non specifica se questa tecnica di persistenza abbia subito variazioni rispetto alla campagna di maggio 2026.

Non è chiaro se l'account npm utilizzato il 7 settembre sia lo stesso compromesso nella campagna @antv o un nuovo account. Il dossier non documenta né l'identità dell'attore né il movente della riattivazione dopo il lungo periodo di inattività.

Il fallimento del publish-time scanning

Il nucleo dell'evento non è la reinfezione in sé, ma la sua capacità di attraversare il controllo di sicurezza che npm aveva promosso come risposta strutturale. A luglio 2026, il registry ha introdotto il publish-time malware scanning, trattenendo i pacchetti 5-15 minuti per analisi automatica prima della pubblicazione effettiva.

Un payload con hash identico e pubblico da quattro mesi rappresenta il caso più semplice per un sistema di detection. "A file hash match is a lookup, not a hard problem. It requires no behavioral analysis, sandboxing, or reasoning about obfuscated code's intent", ha scritto Aikido. La rilevazione per hash è un confronto diretto tra un artifact in transito e un database di indicatori noti: non richiede decompilazione, esecuzione in sandbox o analisi euristica del comportamento.

Il superamento di questa barra minima solleva un interrogativo più ampio. "If this is what gets through on the easy case, it's worth asking what a payload that bothered to change a single byte would have done", ha aggiunto il team di ricerca. La discrepanza tra la promessa di scanning automatico e la realtà operativa diventa il centro della lettura: il registry-level scanning non ha funzionato nemmeno quando l'attaccante non ha tentato di evaderlo.

"Signature matching against known-malicious artifacts is the single easiest bar to clear in this industry, and it's the bar we should all be most alarmed to see missed." — Aikido research team

Perché è importante

Il dossier non specifica se npm abbia successivamente rimosso i quattro pacchetti, né quanto tempo siano rimasti disponibili per installazione. Non è quantificato il numero di download effettivi prima dell'eventuale rimozione. Non è documentata alcuna risposta ufficiale di npm o aggiornamento del sistema di scanning dopo l'incidente del 7 settembre.

La fonte non chiarisce se esistano varianti con hash modificati che siano passate simultaneamente al match esatto, rendendo impossibile stabilire se il fallimento sia isolato o sistemico. La natura dei dati esposti dalle installazioni — token, scope di pubblicazione, o altri asset — non è dettagliata oltre il meccanismo di furto dei token npm già descritto.

Per gli sviluppatori e i team DevOps, l'evento documenta che il registry-level scanning non costituisce una garanzia sufficiente per minacce note. Per il settore della supply-chain security, solleva interrogativi sulla efficacia delle promesse di "scanning automatico" come controllo primario. Per le aziende, richiede verifica della presenza di pacchetti compromessi in cache locali e pipeline CI, anche se il brief non documenta misure correttive specifiche da adottare.

Il contesto della campagna @antv

Il 19 maggio 2026, la campagna originaria di Shai-Hulud — denominata Mini Shai-Hulud da Aikido — aveva compromesso 639 versioni di pacchetti dello scope @antv in un'ora, attraverso un account maintainer compromesso. La scala dell'operazione aveva dimostrato la velocità di propagazione del worm e la sua capacità di sfruttare permessi di pubblicazione legittimi per auto-replicarsi.

La connessione tra la campagna di maggio e il ritorno di settembre è limitata all'identità dell'hash e del dominio C2. Il dossier non stabilisce se l'attore sia lo stesso, se il modus operandi sia identico, o se la riattivazione rappresenti una ripresa deliberata o un tentativo di testare i controlli del registry. La dormienza di 111 giorni rimane un dato di fatto senza interpretazione confermata sulle motivazioni.

La ripubblicazione di un payload non modificato, dopo un periodo di assenza così lungo, ha funzionato involontariamente come test di regressione: il sistema di sicurezza introdotto nel periodo intermedio non ha superato la verifica più elementare. Questa lettura, derivata direttamente dall'analisi di Aikido, non presuppone che il scanning sia inutilizzabile in ogni scenario, ma documenta che ha fallito in questo specifico e su un criterio di detection basico.

Domande e risposte

È stato modificato il codice del worm per eludere il scanning?
No. Il dossier documenta esplicitamente che il payload non è stato repacked, offuscato o modificato: è un match esatto di hash noto da mesi.

I quattro pacchetti sono ancora disponibili su npm?
La fonte non specifica se npm li abbia rimossi o quanto tempo siano rimasti pubblicati dopo il 7 settembre 2026.

Quante installazioni sono state registrate?
Il dossier non quantifica il numero di installazioni effettive dei pacchetti prima di un'eventuale rimozione.

Fonti

• https://www.aikido.dev/blog/shai-hulud-npm-resurfaces
• https://www.cryptika.com/shai-hulud-npm-worm-resurfaces-after-111-days-and-slips-past-malware-scanning/
• https://gbhackers.com/npm-worm-returns-after-111-days/
• https://www.aikido.dev/blog/mini-shai-hulud-antv-npm-supply-chain-attack

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti