ChainDrop: il worm npm che ha compromesso 444 pacchetti in meno…

Analisi dell'attacco ChainDrop del 4 agosto 2026: un worm npm auto-replicante che ha sfruttato OIDC Trusted Publishing con valida provenance SLSA per diffondere

Punti chiave

Il 4 agosto 2026 un worm npm auto-replicante denominato ChainDrop ha compromesso 444 pacchetti e 2.212 versioni in meno di quattro ore, con numeri in continuo aumento
L'attacco è iniziato dal compromesso dell'account GitHub di Jared Wray, maintainer di pacchetti con oltre 150 milioni di download settimanali
I pacchetti malevoli sono stati pubblicati tramite OIDC Trusted Publishing con valida provenance SLSA, rendendo difficile la rilevazione automatica
Il payload di secondo stadio da 727.680 byte rubava credenziali CI/CD per auto-replicarsi e installava persistenza in IDE e strumenti AI
Il C2 sfruttava la tecnica EtherHiding sulla blockchain Ethereum per comandi resistenti alla censura

L'attacco in sintesi

Il 4 agosto 2026, alle 09:02:37 UTC, un commit malevolo (ee2681a, messaggio "release: v6.0.0") è stato pushato nel repository jaredwray/keyv su GitHub. Alle 09:04:30 UTC, un secondo commit (d8c850c, "chore: update config") ha piantato hook di persistenza per IDE e agenti AI.

Entro le 18:10 UTC dello stesso giorno, il worm ChainDrop aveva compromesso 444 pacchetti e 2.212 versioni. Il tutto in meno di quattro ore. I numeri continuavano a crescere al momento della pubblicazione delle analisi tecniche.

L'attacco ha colpito inizialmente tre repository di Jared Wray, maintainer di pacchetti fondamentali dell'ecosistema Node.js: keyv, cacheable, flat-cache, file-entry-cache, cacheable-request, cache-manager e ecto. Solo keyv@6.0.0 contava oltre 150 milioni di download settimanali; flat-cache@6.1.24 ne registrava 149.868.983 e file-entry-cache@11.1.6 ne contava 147.558.494.

"444 packages and 2,212 versions across more than a dozen victim organizations" — StepSecurity, 18:10 UTC 4 agosto 2026

Come funziona il worm

ChainDrop rappresenta un'evoluzione avanzata della famiglia malware Shai-Hulud 2.0, già osservata nella campagna Mini Shai Hulud di maggio 2026 contro TanStack, Mistral AI e OpenSearch. La novità sta nella capacità di auto-propagazione combinata con l'abuso di meccanismi di trust legittimi.

Ogni versione infetta segue lo stesso pattern: uno script preinstall ("node setup.mjs") scarica il runtime JavaScript Bun dai rilasci ufficiali GitHub, poi esegue un payload di secondo stadio da 710 KB (727.680 byte) offuscato, denominato Math_Symbol.js (rinominato math_init.js nella seconda ondata).

Il payload enumerava e rubava credenziali da ambienti CI/CD, con un ampliamento dei target di circa il 70% rispetto alle varianti precedenti: store di credenziali per agenti AI (Claude, OpenAI, Codex, Cursor, Gemini), keystore per criptovalute (Foundry, Solana, Monero), segreti di CI self-hosted (Jenkins master.key, Argo CD, Harbor), configurazioni cloud (Alibaba Cloud, Tencent Cloud) e file di sistema.

Un meccanismo particolarmente insidioso è il "token revocation watcher": il worm installa un monitor che attiva un payload dell'attaccante quando il token GitHub rubato viene revocato, rendendo la semplice rotazione delle credenziali insufficiente a interrompere la compromissione.

La falla nel trust: provenance valida per codice malevolo

Il vettore di distribuzione più disturbante di ChainDrop è l'uso di npm OIDC Trusted Publishing con valida provenance SLSA. Questo meccanismo, progettato per garantire la tracciabilità del software, è stato invece strumentalizzato per conferire legittimità ai pacchetti infetti.

Come hanno osservato i ricercatori StepSecurity: "Provenance proves which commit was built. It cannot prove the commit was authorized." La provenance attesta quale commit è stato compilato, non che il commit fosse autorizzato o legittimo.

I ricercatori Aikido Security, citati da BleepingComputer, hanno confermato: "The compromise was carried out by pushing malicious files directly to the main branch and then immediately cutting a new release, meaning the poisoned versions were published to npm with valid provenance signed by GitHub Actions."

Questo aspetto rende l'attacco particolarmente difficile da rilevare per sistemi di sicurezza automatizzati che si affidano alla presenza di provenance come indicatore di affidabilità.

Cosa fare adesso

Le organizzazioni che utilizzano pacchetti npm devono agire con priorità su tre fronti specifici al caso ChainDrop.

Primo: verificare l'installazione delle versioni compromesse elencate nelle tabelle IOC di StepSecurity. I ricercatori hanno dichiarato esplicitamente: "If you installed any of the affected versions listed below, assume your system is compromised." Le versioni includono keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6 e centinaia di altre.

Secondo: ispezionare i file di persistenza IDE nelle directory di progetto, in particolare .claude/settings.json (hook SessionStart) e .vscode/tasks.json (runOn: folderOpen), oltre a eventuali configurazioni GitHub Copilot modificate. Il worm pianta questi hook per mantenere l'accesso anche dopo la rimozione del pacchetto npm.

Terzo: monitorare il dominio npm-cache[.]com identificato da Wiz come infrastruttura di esfiltrazione, e verificare eventuali connessioni a smart contract Ethereum sospetti, dato l'uso della tecnica EtherHiding per C2.

Quarto: considerare che la sola revoca dei token GitHub non è sufficiente. Il token revocation watcher del worm richiede una risposta incident-driven più strutturata, con isolamento dei sistemi compromessi prima della rotazione delle credenziali.

Implicazioni per l'ecosistema open source

L'attacco ChainDrop solleva questioni strutturali sulla sicurezza della supply chain software. I pacchetti compromessi contavano complessivamente 2 miliardi di download mensili secondo BleepingComputer. Le organizzazioni confermate come vittime oltre all'ecosistema jaredwray includono Deliveroo, Ornikar, OneReach, Picsart, Qlik e ServiceTitan.

Jared Wray ha confermato via X di utilizzare OIDC con npm e codici monouso per GitHub, non token statici a lungo termine. Il vettore di compromesso iniziale dell'account rimane non completamente chiarito nelle fonti disponibili. Wray ha riguadagnato l'accesso all'account intorno alle 20:00 UTC del 4 agosto.

Il runtime detonation log di StepSecurity mostra "Suspicious Processes 1" durante l'installazione del tarball keyv alle 11:13:16 UTC del 4 agosto, confermando l'attività malevola in esecuzione.

I ricercatori Expel hanno fornito hash crittografici per gli indicatori di compromissione: per setup.mjs, MD5 f92ee93a0af971a3966bfa8efa9c2625, SHA-1 e65b155ce74f3f81fb7d2b5b60f8e62b36e6d69c, SHA-256 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti