ChainDrop: provenienza valida in oltre 400 pacchetti npm e hook di Claude Code che non richiedono npm install

Il 4 agosto 2026 gli aggressori hanno preso il controllo dell'account GitHub dietro keyv, una libreria di caching che secondo Elastic Security Labs è stata scaricata più di 600 milioni di volte nel mese precedente. Wiz Research e Orca Security riportano entrambe che file malevoli sono stati inviati direttamente al branch main di keyv e che il workflow GitHub Actions del progetto stesso ha quindi compilato e pubblicato la release avvelenata — arrivando così su npm con una provenienza valida, l'attestazione che gli strumenti della supply chain usano per stabilire che un pacchetto è affidabile. Un worm autoripropagantesi che i ricercatori chiamano ChainDrop ha poi utilizzato token npm rubati per ripetere il trucco sui pacchetti di altri maintainer: Elastic ha contato più di 400 pacchetti unici entro il 6 agosto, Microsoft Threat Intelligence ha descritto la stessa campagna il 4 agosto e la Cyber Security Agency di Singapore ha contato oltre 1.300 versioni di pacchetti compromesse con un totale combinato di 2 miliardi di download mensili. Elastic e Microsoft descrivono entrambe hook che vengono rieseguiti quando un repository viene aperto in Claude Code o Visual Studio Code. L'elenco completo delle fonti del record, il grado di gravità e la valutazione della fiducia si trovano in l'archivio degli incidenti AI, insieme alle altre voci relative alla supply chain di npm e degli strumenti per sviluppatori archiviate intorno ad esso.

Come una pipeline di rilascio legittima ha firmato la propria compromissione

Wiz Research ricostruisce i primi minuti: dalle 09:00 UTC del 4 agosto l'attaccante ha utilizzato un'identità compromessa per introdurre payload persistenti per IDE nel repository keyv e, poco dopo, ha pubblicato una nuova versione di keyv contenente il payload. Wiz indica la parte compromessa come un account maintainer di GitHub e afferma che sono seguiti diversi pacchetti nell'ecosistema keyv e cacheable.

Il resoconto di risposta rapida di Orca Security è più specifico sul percorso di firma. Secondo quanto afferma, l'attaccante ha inviato due file malevoli — setup.mjs e Math_Symbol.js — direttamente al branch principale e ha immediatamente pubblicato nuove release. Poiché quelle release sono state create attraverso i workflow GitHub Actions dell'account compromesso, le versioni avvelenate sono state pubblicate su npm con firme di provenienza valide, aggirando i controlli standard di integrità della supply chain. Zscaler ThreatLabz, un team di ricerca indipendente che non figura tra le fonti citate del resoconto, giunge alla stessa conclusione e vi attribuisce un livello: la versione malevola keyv 6.0.0 aveva una valida SLSA Build Level 3 provenienza perché l'attaccante controllava il repository di origine. BleepingComputer, che ha riportato la campagna quel giorno, registra lo stesso meccanismo — file malevoli inviati direttamente ai branch principali dei progetti, nuove release generate, provenienza valida perché le build sono state eseguite tramite workflow GitHub Actions legittimi.

L'analisi di Microsoft aggiunge un dettaglio che sembra una contraddizione e non lo è. Nella fase di propagazione del worm, Microsoft Threat Intelligence ha scoperto che molte versioni malevole non avevano alcun commit corrispondente nel codice sorgente, alcuna pull request, alcun tag o alcuna release legittima, il che indicava che gli attaccanti modificavano e pubblicavano direttamente i tarball dei pacchetti invece di compromettere ciascun repository pubblico del codice sorgente. Lette insieme, le fonti descrivono due regimi di firma all'interno di una stessa campagna: le prime release di keyv passavano attraverso la vera pipeline CI della vittima e portano attestazioni che le convalidano, mentre le release successive del worm sono state in gran parte assemblate e pubblicate con token del registry rubati, senza lasciare alcuna traccia nel codice sorgente. L'osservazione di Microsoft stessa è che il pattern della pubblicazione diretta dei tarball spiega perché le release malevole apparivano spesso come un normale incremento di versione patch senza commit o pull request corrispondenti nel codice sorgente.

La lezione scomoda è enunciata chiaramente da Zscaler: la provenienza convalida il processo di compilazione, non l’identità dell’account né l’integrità del sistema CI che lo esegue. Riconosce inoltre una lacuna che conta per chiunque ricostruisca l’incidente — l’esatto meccanismo di takeover dell’account utilizzato dall’attaccante era sconosciuto al momento della sua analisi.

Cosa viene eseguito durante npm install: preinstall, Bun 1.3.13 e un raccoglitore di 300 pattern

Elastic Security Labs descrive il trigger come un preinstall hook in package.json, che sfrutta una funzionalità npm legittima che esegue comandi arbitrari prima che un pacchetto completi l'installazione, senza richiedere ulteriori interazioni da parte della vittima. L'hook avvia setup.mjs, che controlla se il runtime JavaScript Bun è già presente. In caso contrario, il dropper rileva la piattaforma e l'architettura della macchina, scarica Bun v1.3.13 dalla pagina di rilascio ufficiale, lo estrae, lo usa per eseguire il payload e poi elimina la directory temporanea per coprire le proprie tracce. Wiz ha identificato in modo indipendente lo user agent Bun/1.3.13 che effettua le chiamate malevole. Il dropper è multipiattaforma e prende di mira Linux, macOS e Windows.

Il payload è fortemente offuscato, e le fonti differiscono leggermente sulla sua dimensione: Elastic lo colloca a 711 kilobyte, Orca Security a 728 KB. Usa il control-flow flattening e uno schema di codifica delle stringhe Base91, e contiene stringhe a tema Dune — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — che Elastic nota avere similarità con precedenti campagne Shai-Hulud.

Il resoconto comportamentale di Microsoft aggiunge due dettagli utili. Il payload controlla prima il proprio ambiente e termina sui sistemi in lingua russa, evita istanze duplicate e avvia una copia in background distaccata sulle workstation degli sviluppatori; all'interno della CI rimane collegato al job attivo per poter raggiungere i segreti del workflow, le credenziali del runner e le autorizzazioni di pubblicazione OpenID Connect.

Il collector è il punto in cui l'incidente diventa una storia di strumenti AI anziché una storia generica di credenziali. Elastic afferma che esegue la scansione di oltre 300 pattern unici negli archivi di credenziali su una macchina per sviluppatori, e che il targeting notevole è rivolto alle credenziali degli strumenti AI: Anthropic, Claude, Codex, Cursor, OpenAI e Gemini. Acquisisce anche credenziali AWS, GCP, Azure e Alibaba Cloud, token di accesso personale GitHub, token JWT e di sessione, token HashiCorp Vault, chiavi private SSH, token degli account di servizio Kubernetes e token npm. Wiz segnala che l'elenco degli obiettivi è stato ampliato di quasi il 70% rispetto al precedente codice Mini Shai-Hulud su cui è basato, con nuove aggiunte tra cui archivi di credenziali degli agenti AI per Claude, OpenAI, Codex, Cursor e Gemini, keystore di criptovalute per Foundry, Solana e Monero, master.key di Jenkins, secret di Argo CD e Harbor, configurazioni CLI di Alibaba e Tencent e /etc/shadow.

Sia Microsoft sia Elastic descrivono lo stesso design di esfiltrazione. I risultati vengono serializzati come JSON, compressi con gzip e crittografati con una chiave AES-256-GCM generata casualmente, e tale chiave viene avvolta con la chiave pubblica RSA dell'attaccante. Il payload non codifica direttamente il proprio dominio di command-and-control: Elastic afferma che interroga uno smart contract Ethereum presso 0xE1f2395ee43e45A1556EC6438a88c31B83493103 per recuperare l'endpoint corrente a runtime, così l'infrastruttura può essere ruotata senza modificare il malware. Se ciò non riesce, cerca un marker firmato crittograficamente — thebeautifulmarchoftime — nella cronologia dei commit di GitHub e convalida il dominio rispetto a una chiave RSA incorporata. Se entrambi falliscono, esfiltra tramite un repository GitHub pubblico creato dall'account stesso della vittima, descritto come "Shai-Hulud: Here We Go Again". Microsoft nota che un percorso di fallback codifica un token GitHub rubato con doppio Base64 anziché crittografarlo.

La propagazione è subordinata alla qualità del token. Elastic riferisce che il worm si attiva solo quando la scansione delle credenziali trova un token npm con permessi di scrittura sui pacchetti e la capacità di pubblicare senza autenticazione a due fattori; poi scarica l'ultimo tarball di ogni pacchetto scrivibile, si inietta, incrementa la versione patch e ripubblica. BleepingComputer aggiunge che ogni token viene validato in tempo reale tramite l'endpoint whoami del registro prima di essere rubato. È questa routine che ha trasformato una singola identità compromessa in centinaia di rilasci, ed è il motivo per cui le versioni malevole sembrano normali incrementi di patch.

Il percorso di infezione che non richiede npm install

La scoperta che distingue questa campagna dai precedenti worm npm è che l'installazione non è più l'unica via d'ingresso. Elastic descrive due ulteriori percorsi di esecuzione rivolti agli utenti di strumenti di programmazione AI. Un hook SessionStart in .claude/settings.json esegue node .claude/setup.mjs all'avvio di una nuova sessione Claude. Per VS Code, un'attività folderOpen in .vscode/tasks.json esegue node .vscode/setup.mjs all'apertura di un repository infetto. L'analisi di Microsoft elenca gli stessi quattro artefatti — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json e .vscode/setup.mjs — e li descrive come una via di infezione secondaria che può riavviare il payload dopo il completamento dell'installazione npm originale.

La condizione che amplia drasticamente questo quadro risiede nelle credenziali rubate. Quando un GitHub App token è tra queste, Elastic riferisce che il worm esegue il commit degli hook malevoli su fino a 50 branch per ogni repository accessibile, iniettando .claude/settings.json e .vscode/tasks.json in ciascuno. La conclusione di Elastic è che uno sviluppatore che clona uno di quei branch e lo apre può essere infettato semplicemente aprendo il progetto — nessuna installazione di pacchetti, e quindi nessuna difesa basata sugli script di installazione, lungo il percorso.

La valutazione di Zscaler è che gli hook di persistenza sopravvivono alla rimozione del pacchetto e si rieseguono semplicemente aprendo il progetto in VS Code o Claude Code, il che aggira la --ignore-scripts mitigazione che molte squadre hanno adottato dopo i precedenti worm npm. La sua raccomandazione consegue direttamente: trattare i file di configurazione di IDE e agenti AI — .claude/, .cursor/, .vscode/, .gemini/ — come codice eseguibile, revisionati con lo stesso rigore del codice sorgente.

Esiste un'impronta digitale per la parte relativa al repository dell'attacco. Elastic riporta che i commit generati dal worm possono essere identificati tramite il nome dell'autore claude e il messaggio di commit chore: update config, e Wiz registra la stessa stringa di messaggio. Elastic aggiunge che il messaggio di commit conteneva anche il token GitHub rubato insieme a una stringa di intimidazione — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — che interpreta come un tentativo di spaventare gli sviluppatori inducendoli a non revocare il token. Wiz registra la stessa stringa nei commit iniziali, con il messaggio più breve inserito nei commit che introducono gli hook dell'IDE.

I conteggi non concordano, e questa non è una contraddizione

Ogni cifra pubblicata per il raggio d'impatto è associata a un'unità diversa, e le unità non sono intercambiabili. Elastic Security Labs, in un articolo del 6 agosto, ha contato oltre 400 pacchetti npm unici compromessi. Microsoft Threat Intelligence ha descritto più di 400 pacchetti presso più editori non correlati. Aikido, citato da BleepingComputer, lo ha quantificato in almeno 868 pacchetti su 1.381 versioni. Orca Security segnala 10 pacchetti keyv e cacheable direttamente avvelenati con oltre 619 milioni di download mensili, poi altri 868 pacchetti e 1.381 versioni raggiunti dal worm, per oltre 2 miliardi di installazioni mensili. L'avviso AD-2026-009 della CSA di Singapore, datato 6 agosto, registra oltre 1.300 versioni di pacchetti compromesse che rappresentano un totale combinato di 2 miliardi di download mensili.

Quelli sono tre denominatori diversi — pacchetti, versioni dei pacchetti e volume mensile di download — rilevati in tre momenti diversi di una campagna ancora in corso. Il resoconto di Zscaler sulla velocità spiega perché divergono: afferma che il worm si è auto-propagato a più di 400 pacchetti in meno di quattro ore e, al picco, pubblicava all'incirca un pacchetto infetto al secondo. Considerare un conteggio successivo come una correzione di uno precedente sarebbe sbagliato; ciascuno è un'istantanea, e nessuna delle fonti citate dichiara un totale finale.

Le cifre di esposizione di Elastic a livello di libreria sono quelle più spesso citate e meno ambigue. Riporta keyv da solo a oltre 600 milioni di download il mese precedente, con flat-cache vicino a 580 milioni, cacheable-request oltre 137 milioni, cacheable oltre 30 milioni e cache-manager oltre 16 milioni. L'avviso di CSA elenca le specifiche versioni compromesse, tra cui keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 ed ecto 5.0.1.

La trappola della revoca

I responder che hanno installato una versione interessata affrontano un secondo problema dopo il primo. Elastic riferisce che in un percorso di fallback GitHub condizionale il payload tenta di installare un componente di monitoraggio dei token che mantiene l'accesso alle credenziali e contiene un handler distruttivo se il token monitorato viene revocato. Zscaler descrive il meccanismo in dettaglio operativo e lo definisce una trappola di revoca del token: il worm installa un processo in background che interroga l'API di GitHub ogni 60 secondi con il token rubato, e se il token restituisce un errore 4xx — che significa che la vittima lo ha revocato — viene attivato un payload distruttivo secondario, che a seconda della variante può includere l'esecuzione di codice remoto o l'eliminazione della directory home dell'utente.

Wiz aggiunge che il dead-man's switch è armato selettivamente in base a una risposta del server di comando e controllo: l'operatore può restituire un valore che specifica quale comando armare e quale token l'interruttore deve monitorare ai fini della revoca. Wiz osserva inoltre che il monitor cerca una risposta valida dall'endpoint dell'utente, pertanto qualsiasi tipo di token valido lì può fungere da trigger.

La conseguenza pratica è documentata da BleepingComputer e dalle indicazioni di Aikido che esso cita: una workstation di sviluppo o un runner CI/CD che ha installato una versione interessata deve essere considerato compromesso anche se il pacchetto è stato successivamente rimosso, perché l'esecuzione della seconda fase può aver esposto token e compromesso l'integrità della build. Le indicazioni di Microsoft giungono alla stessa conclusione dal lato della build, avvertendo che le organizzazioni che hanno installato un pacchetto interessato con gli script del ciclo di vita abilitati dovrebbero considerare la workstation o il runner di build come potenzialmente compromessi e ricostruire da fonti attendibili i sistemi interessati e gli artefatti downstream.

Ciò che è stabilito, ciò che è valutato e ciò che nessuno ha dimostrato

Il documento primario e cinque analisi indipendenti convergono sulla meccanica, e le tesi di natura meccanica sono la parte più solida del fascicolo.

• L'account GitHub del manutentore di keyv è stato compromesso e file malevoli sono stati inviati direttamente su main prima che venisse pubblicata una release, il 4 agosto 2026 — segnalato in modo concordante da Wiz, Orca Security, BleepingComputer e CSA Singapore.

• Almeno keyv 6.0.0 è arrivato su npm attraverso la pipeline CI della vittima stessa, con una provenienza valida, e Zscaler specifica un'attestazione SLSA Build Level 3. È questa l'affermazione che rende l'incidente degno di nota, ed è corroborata da tre organizzazioni che non hanno collaborato tra loro alla stesura del lavoro.

• Un hook di preinstallazione ha eseguito setup.mjs, che ha scaricato Bun v1.3.13 e ha lanciato un payload offuscato che ha analizzato oltre 300 pattern di credenziali, comprese le credenziali degli strumenti di coding AI — Elastic e Wiz concordano sia sulla versione del runtime sia sull'elenco delle credenziali mirate all'AI.

• Gli hook scritti in .claude/settings.json e .vscode/tasks.json vengono eseguiti all'avvio della sessione e all'apertura della cartella, e un token di GitHub App ha esteso questo comportamento fino a 50 branch per repository accessibile — la scoperta di Elastic, e la base della sua affermazione secondo cui uno sviluppatore può essere infettato aprendo un repository.

• Più di 400 pacchetti unici sono stati compromessi nel giro di pochi giorni, e CSA Singapore, un ente regolatore nazionale, ha pubblicato l'avviso AD-2026-009 il 6 agosto 2026, elencando le versioni interessate e gli indicatori.

Quello che le fonti trattano come valutazione anziché come fatto dovrebbe essere etichettato. Wiz descrive il payload come un discendente della famiglia di malware "Mini" Shai-Hulud, costruito su repository pubblici Shai-Hulud-Open-Source pubblicati da TeamPCP, con alcune modifiche cruciali; Orca Security attribuisce l'attacco a TeamPCP; Zscaler collega ChainDrop a TeamPCP e lo colloca in una discendenza che risale a settembre 2025. Si tratta di un consenso di attribuzione tra i fornitori, non di qualcosa che un documento primario citato dimostri riguardo a un individuo o a un gruppo nominato.

Tre cose che nessuna fonte citata stabilisce, e che questo articolo non colma. Primo, come l'account del manutentore sia stato compromesso: Zscaler afferma chiaramente che il meccanismo esatto era sconosciuto al momento della sua analisi. Secondo, un unico totale finale: le cifre 400, 868 e 1.300 contano pacchetti, pacchetti-e-versioni e versioni in momenti diversi, e nessuna fonte afferma che la campagna sia conclusa. Terzo, e cosa più importante per l'affermazione specifica sull'AI in questo record, nessuna fonte citata riporta un caso confermato in cui una credenziale rubata di Anthropic, Codex, Cursor, Gemini o OpenAI venga riprodotta contro l'account di un provider. Ciò che è documentato sono l'intenzione e la capacità — un elenco esplicito di obiettivi e un collettore costruito per raggiungerlo — non una violazione downstream dimostrata dei sistemi di un provider di AI.

Cosa è cambiato dopo — e cosa deve fare chi interviene

Il rimedio più concreto riportato nel documento è una modifica della piattaforma. Elastic consiglia di eseguire l'aggiornamento a npm 12 o versione successiva, che blocca per impostazione predefinita gli hook preinstall; le indicazioni di Microsoft consigliano in modo indipendente npm CLI v12 e la funzionalità min-release-age, che trattiene le nuove versioni abbastanza a lungo perché la community possa individuare una compromissione prima che raggiunga una build.

Oltre a ciò, le fasi di risposta pubblicate dalle fonti si sovrappongono in larga misura.

• Elastic: revoca tutti i token GitHub, inclusi i token di sessione sulle macchine interessate; revoca e rigenera i token npm, in particolare i token di automazione con permessi di scrittura e bypass dell'autenticazione a due fattori; cerca nei repository commit non autorizzati con il messaggio chore: update config from claude@users.noreply.github.com; ruota i segreti di cloud, Kubernetes, Vault, AI-tooling e CI/CD; abilita l'autenticazione a due fattori sugli account npm.

• Microsoft: svuotare le cache npm e yarn sugli endpoint interessati e sugli host di build, fissare le versioni note come valide, esaminare i lockfile e gli artefatti per individuare le versioni compromesse, compresi i riferimenti transitivi, ricostruire le immagini base condivise e i runner di build golden, e riesaminare gli ambiti dei token, le approvazioni dei workflow e la provenienza delle release, poiché l'incidente è coerente con un abuso della pipeline CI/CD tramite pubblicazione OIDC.

• CSA Singapore: rimuovere le versioni interessate dagli ambienti di sviluppo, build e CI/CD, trattare i sistemi interessati come compromessi e ricostruirli, ruotare le credenziali, verificare gli ambienti cloud e del codice sorgente per accessi non autorizzati, monitorare gli indicatori pubblicati e rafforzare l'allowlisting, la verifica dell'integrità e i controlli di provenienza.

• Zscaler: trattare .claude/, .cursor/, .vscode/ e .gemini/ come codice eseguibile e smettere di considerare la provenienza SLSA o Sigstore come prova di sicurezza, affiancandola invece al rilevamento di anomalie nel comportamento di pubblicazione, come pubblicazioni fuori orario, pubblicazione in blocco di versioni e publisher alla prima pubblicazione.

Il record non contiene un esito di remediation. Nessuna fonte citata riporta la rimozione completa delle versioni malevole, un recupero dell'account, un arresto o un'azione di enforcement regolatorio; l'avviso di CSA è una notifica ai difensori, non una constatazione a carico di una parte.

Ciò che l'incidente cambia è una classificazione. Un file di configurazione di uno strumento per sviluppatori è un percorso di esecuzione, e un editor che apre una cartella è un evento di esecuzione. E un'attestazione di provenienza è un'affermazione su quale pipeline ha prodotto un pacchetto — non su chi deteneva le chiavi quando quella pipeline è stata eseguita, che è precisamente la lacuna che il primo rilascio di keyv ha lasciato scoperta.