Il 4 agosto 2026 un worm auto-propagante ha attraversato l'ecosistema npm in meno di quattro ore, infettando 444 pacchetti e 2.212 versioni con payload crittograficamente attestati come legittimi. ChainDrop non ha sfruttato una vulnerabilità nel registro né nei protocolli di firma: ha usato OIDC Trusted Publishing e attestazioni SLSA proprio come fa chiunque pubblichi software affidabile. La differenza stava solo nel controllo dell'account compromesso.
L'attacco dimostra che la provenance automatizzata, da sola, non distingue più il software sicuro da quello malevolo. Quando il punto di ingresso è un maintainer di alto profilo con workflow fidato, la firma diventa un velo anziché un filtro.
- Il worm ChainDrop ha infettato 444 pacchetti npm e 2.212 versioni tra le 09:40 e le 13:20 UTC del 4 agosto 2026, secondo StepSecurity; il conteggio continuava a salire alle 18:10 UTC.
- I pacchetti iniziali portavano attestazioni SLSA valide pubblicate via OIDC Trusted Publishing, rendendoli indistinguibili da release legittime per qualsiasi verifica automatizzata.
- Il payload di ~710 KB usa il runtime Bun legittimo come veicolo di esecuzione, ruba credenziali CI/CD e sviluppatore da filesystem, variabili d'ambiente e memoria processo, poi si ripropaga autonomamente su npm.
- L'infrastruttura di comando e controllo si appoggia a uno smart contract Ethereum che aggiorna dinamicamente i domini C2; Unit 42 ha osservato la riconfigurazione completa via singola transazione il 4 agosto tardi.
Come è iniziata l'infezione: un account, non una vulnerabilità
L'innesco è avvenuto alle 09:02:37 UTC con commit avvelenati pushati dall'account GitHub di Jared Wray, maintainer di pacchetti ad alto traffico nell'ecosistema npm. Non risulta, dalle fonti disponibili, quale vettore abbia compromesso l'accesso iniziale: phishing, credential stuffing o altro meccanismo restano non confermati. Wray ha successivamente dichiarato, secondo CSO Online, di aver usato OIDC e one-time codes, non token statici a lungo termine, e di aver riguadagnato il controllo dell'account alle 20:00 UTC.
Da quel primo accesso, i pacchetti carrier sono stati pubblicati attraverso i workflow automatizzati di Trusted Publishing. StepSecurity annota che gli 11 pacchetti tier 1 — tra cui keyv@6.0.0, flat-cache@6.1.24 e file-entry-cache@11.1.6 — contavano oltre 450 milioni di download settimanali combinati. Flat-cache da solo ne registrava 150.868.983. Questi pacchetti sono dipendenze transitive di strumenti ubiqui come ESLint; la loro installazione avviene spesso senza esame diretto da parte degli sviluppatori finali.
Il meccanismo del dropper: Bun come veicolo, non come bersaglio
I pacchetti compromessi eseguono un hook preinstall che lancia setup.mjs. Questo script controlla la presenza del runtime Bun nel PATH; se assente, lo scarica dalla repository GitHub ufficiale di Oven, la società che lo sviluppa. Palo Alto Networks Unit 42 chiarisce: "To be clear: Bun is not compromised. The attacker is using a legitimate runtime as a portable execution vehicle." Il runtime legittimo diventa così il contenitore portabile per il payload successivo.
Il payload di secondo stadio — Math_Symbol.js, noto anche come math_init.js — è un file JavaScript offuscato di 727.680 byte, compresso in due righe. La sua dimensione (~710 KB) lo rende rilevabile in teoria, ma la sua consegna attraverso un runtime noto e la sua esecuzione nel contesto di installazione dipendenze riducono la visibilità operativa.
Il worm adatta il proprio comportamento all'ambiente. Su workstation sviluppatore si distacca in background; nei runner CI, invece, resta inline nel job per catturare segreti del workflow. Unit 42 riporta che "if it detects a CI environment it runs inline in the job instead, which means its own debug output lands in the workflow log" — un dettaglio che ha permesso osservazione retrospettiva, ma che non ha impedito l'esecuzione iniziale.
Il furto di credenziali: dalla memoria del runner ai token npm
Il payload implementa un meccanismo di scraping della memoria particolarmente aggressivo. Un helper Python embedded nel blob cifrato localizza il processo Runner.Worker su GitHub Actions, apre /proc/<pid>/maps e /proc/<pid>/mem, estraendo token OIDC temporanei e altri segreti del runner. Unit 42 sottolinea: "Rather than waiting for a file to be written to disk, the worm searches memory. In the process, it captures secrets that may have been designed to vanish when a job finishes." I token OIDC sono progettati per scadenza breve; l'accesso alla memoria li rende vulnerabili prima della naturale eliminazione.
Le credenziali rubate — da filesystem, variabili d'ambiente, memoria processo — abilitano l'autenticazione a npm, GitHub, AWS, Kubernetes e HashiCorp Vault. Il worm verifica permessi package-write e bypass 2FA, quindi scarica tarball, inserisce il malware, incrementa la patch version e ripubblica. Microsoft Threat Intelligence descrive questa routine: "payload's package-propagation routine downloads each publisher's latest release, inserts itself, increments the patch version, and publishes the resulting archive." I 433 pacchetti tier 2 sono stati generati automaticamente con questo meccanismo, oltre agli 11 carrier iniziali.
Persistenza cross-linked: quando VS Code e Claude Code diventano vettori
ChainDrop non si limita alla pipeline di installazione npm. L'analisi deobfuscated di Unit 42 mostra una persistenza cross-linked tra ambienti di sviluppo: il file .vscode/tasks.json contiene un task "Environment Setup" con runOn: folderOpen che esegue node .claude/setup.mjs; viceversa, .claude/settings.json imposta un SessionStart hook che esegue node .vscode/setup.mjs. Unit 42 definisce questo meccanismo "cross-referencing is a naming trick that makes each artifact look like it belongs to the other tool."
Questa architettura espande la superficie di attacco oltre l'IDE tradizionale, toccando gli assistant AI integrati nel flusso di lavoro degli sviluppatori. Microsoft Threat Intelligence ha analizzato specificamente la componente "Mini Shai-Hulud" e la sua persistenza in Claude Code. L'infezione diventa così un percorso sviluppatore-a-sviluppatore, indipendente dall'installazione npm originale.
Unit 42 segnala inoltre routine decifrate per token-monitor persistenti su macOS (LaunchAgent) e Linux (systemd service), ma precisa che nel campione analizzato queste routine non erano state invocate. Il loro stato di attivazione in ambienti reali resta non verificato dalle fonti disponibili.
C2 su blockchain: l'irraggiungibilità del takedown tradizionale
L'infrastruttura di comando e controllo si appoggia a uno smart contract Ethereum all'indirizzo 0xE1f2395ee43e45A1556EC6438a88c31B83493103, con selector 0x53ed5143. Il malware risolve dinamicamente l'endpoint C2 interrogando la blockchain; il dominio attivo risulta npm-cache[.]com. Il 4 agosto 2026 tardi, Unit 42 ha osservato l'avversario "silently reconfiguring the worm's entire C2 infrastructure through a single Ethereum transaction, without requiring any update to the deployed malware." Il fallback opera su repository GitHub pubblici con descrizione "Shai-Hulud: Here We Go Again", identificati da Unit 42 in 453 repository — rimossi al momento della pubblicazione dell'analisi.
L'uso di Ethereum per C2 rende inefficace il takedown basato su abuse reporting verso registri DNS o provider hosting: la blockchain non prevede un'autorità centrale che possa bloccare o modificare uno smart contract. L'exfiltrazione dei dati stessi utilizza cifratura AES-256-GCM con chiave casuale, poi cifrata con RSA-OAEP-SHA256 della chiave pubblica dell'attaccante.
"Provenance proves which commit was built. It cannot prove the commit was authorized." — StepSecurity
Cosa fare adesso
Microsoft Threat Intelligence indica: "Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised." Dalle fonti disponibili emergono le seguenti azioni prioritarie:
- Considerare compromessa qualsiasi workstation sviluppatore o runner CI/CD che abbia installato versioni affette durante la finestra 09:40-13:20 UTC del 4 agosto 2026, con rotazione completa delle credenziali.
- Verificare la presenza di file .vscode/tasks.json e .claude/settings.json con riferimenti incrociati a setup.mjs, indicatore della persistenza cross-linked documentata da Unit 42.
- Controllare la generazione di repository GitHub pubblici con descrizione "Shai-Hulud: Here We Go Again", pattern di fallback exfiltration identificato da Microsoft Threat Intelligence.
- Richiedere rebuild da fonti attendibili con verifica manuale del codice sorgente, dato che le attestazioni SLSA automatizzate non hanno impedito la distribuzione del payload.
La lezione: la provenance è genealogia, non garanzia
StepSecurity formula il problema con precisione sintetica: la provenance attesta da quale commit deriva un artefatto, non che il commit fosse legittimo. ChainDrop sfrutta questa distinzione operativa: i meccanismi crittografici funzionano correttamente, ma il punto di ancoraggio della fiducia — l'account del maintainer — è cedevole. L'assunzione che provenance valida equivalga a sicurezza si è rivelata un singolo punto di fallimento concettuale.
L'impatto per il settore supera l'incidente specifico. I controlli di provenance automatizzati, sempre più adottati come requisiti compliance, non rilevano account compromessi con workflow legittimi. L'uso di blockchain per C2 aggiunge una dimensione di irraggiungibilità legale. La persistenza in AI coding assistant espande il perimetro oltre quello tradizionale. La combinazione di questi elementi definisce un nuovo standard di sofisticazione per gli attacchi alla supply chain software.
Il worm era attivo e in propagazione al momento delle pubblicazioni delle analisi. Nessuna fonte indica eradicazione completa.
Perché i pacchetti malevoli avevano attestazioni SLSA valide?
Le attestazioni SLSA verificano la derivazione dell'artefatto da un commit specifico tramite workflow fidato. Poiché l'attaccante controllava l'account GitHub del maintainer, ha potuto eseguire i workflow legittimi di OIDC Trusted Publishing, generando attestazioni crittograficamente corrette per commit avvelenati. La firma è valida; lo scopo è fraudolento.
Il runtime Bun è stato compromesso?
No. Bun è un runtime legittimo sviluppato da Oven. L'attaccante lo scarica dalla repository ufficiale e lo usa come veicolo di esecuzione portabile per il payload offuscato. Il runtime stesso non contiene codice malevolo; è lo strumento, non il bersaglio.
Qual è il significato del controllo sulla lingua russa nel payload?
Il payload contiene una routine che esce silenziosamente su sistemi con locale russo, stampando "Exiting as russian language detected!". Questo pattern è documentato dalle fonti tecniche, ma il movente — deterrenza, evitare bersagli specifici, o altro — non è confermato nel dossier disponibile.
Fonti
- https://www.stepsecurity.io/blog/chaindrop-npm-worm
- https://unit42.paloaltonetworks.com/chaindrop-npm-worm-analysis/
- https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/
- https://www.csoonline.com/article/4205276/chaindrop-credential-stealing-worm-infects-over-400-npm-packages.html
- https://www.stepsecurity.io/start-free
- https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/30903869229?tab=process-events&jobId=91974344803
- https://docs.stepsecurity.io/workspace/threat-center
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.