In questo articolo Indice dei contenuti 2 sezioni
Un worm diffuso tramite pacchetti npm è riuscito a infettare 42 repository GitHub riconducibili a 11 proprietari legittimi, nascondendo il malware dentro file JavaScript così voluminosi da sfuggire ai normali strumenti di ricerca della piattaforma. L’operazione, battezzata testmetest, mette insieme una combinazione piuttosto insolita di payload offuscati da oltre 12 MB, credenziali rubate agli sviluppatori e meccanismi di avvio automatico agganciati agli assistenti AI per la programmazione.
Ad analizzare a fondo la campagna sono stati Guy Korolevski e Yair Benamou di JFrog Security Research. Il caso si aggiunge alla lunga serie di attacchi alla supply chain software che nel 2026 hanno preso di mira npm e GitHub, a cominciare dalla campagna Mini Shai Hulud con i suoi 314 pacchetti coinvolti fino alle varianti in grado di propagarsi da sole attraverso librerie e repository compromessi. Nell’elenco figurano anche la compromissione della libreria Axios, l’attacco ai pacchetti npm legati a Red Hat e la campagna Megalodon, arrivata a toccare oltre 5.500 repository. Sono operazioni diverse ma unite da un filo comune fatto di credenziali sottratte, automatismi di pubblicazione e fiducia riposta nei componenti distribuiti dai canali ufficiali.
C’è poi un dettaglio che preoccupa parecchio. Secondo la prima indagine di SafeDep, testmetest sembrava confinato ad account gestiti dagli stessi aggressori. JFrog ha invece scovato repository autentici già compromessi, con attività che risalgono addirittura a luglio 2026. Non si trattava quindi di un semplice esperimento preparatorio.
Dai pacchetti npm ai file giganti che la ricerca non vede
Il punto d’ingresso sono alcuni pacchetti npm con nomi e descrizioni del tutto simili a quelli di normali librerie JavaScript. SafeDep ne aveva individuati 18 pubblicati tra il 19 e il 25 ottobre, mentre l’analisi successiva di JFrog ha allargato l’inventario a 25 nomi e 82 versioni complessive, comprese release innocue e componenti usati come copertura.
Una delle tecniche iniziali sfrutta binding.gyp, il file di configurazione legato alla compilazione dei moduli nativi Node.js. Gli aggressori vi inseriscono un comando che lancia index.js durante l’installazione, senza bisogno di dichiarare il classico script install nel package.json. Il caricatore trasforma i caratteri, decifra uno stadio protetto con AES 128 GCM e recupera oppure scarica Bun 1.2.18 per eseguire il passaggio successivo. In certe varianti il codice gira direttamente in memoria, in altre transita per qualche istante sul disco.
La vera novità però sta nelle dimensioni. Nei repository colpiti sono comparsi file .github/init.js tra circa 12,9 e 13,7 MB, pensati per ospitare un caricatore offuscato e un secondo stadio nascosto. La ricerca del codice di GitHub non li indicizzava e anche le richieste alla Contents API non riuscivano a restituirne il contenuto. Nella prima ricognizione JFrog aveva trovato tracce in 26 repository, ma i file principali apparivano praticamente vuoti. Solo passando alle Git Trees API e Git Blobs API, enumerando direttamente gli oggetti Git, sono emersi i payload reali. Estendendo i controlli agli altri progetti degli stessi proprietari il conto è salito a 42. I ricercatori hanno poi identificato dieci varianti dei file, diverse per codifica dei caratteri e chiavi di rotazione, che una volta decodificate portano tutte allo stesso payload con identico hash SHA256.
Claude, Gemini, Cursor e VS Code come inneschi
La seconda fase colpisce gli strumenti di tutti i giorni. I repository infetti contenevano configurazioni che sfruttavano gli hook di esecuzione automatica di assistenti AI e ambienti di sviluppo, tra cui .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc e .vscode/tasks.json. Con Claude Code, per esempio, un hook SessionStart richiama node .github/init.js oppure prova ad avviarlo con Bun. Meccanismi equivalenti erano predisposti per Gemini, Cursor e Visual Studio Code. Un progetto clonato può così tentare di eseguire codice all’apertura di una sessione, sempre che lo strumento in uso permetta davvero l’attivazione di quei meccanismi.
Per scovare i repository compromessi non basta la ricerca testuale di GitHub. Bisogna esaminare direttamente alberi Git, blob e modifiche, prestando attenzione a init.js, alle configurazioni degli assistenti AI, ai workflow GitHub Actions inattesi, ai branch temporanei con prefisso chore/ci o deps/upd, ai commit che chiedono di saltare i controlli e ai file .napi_cache legati a moduli nativi sospetti.
Chi ha installato una delle versioni malevole dovrebbe considerare il sistema compromesso, ricostruire l’ambiente da fonti affidabili e cambiare le credenziali accessibili al processo infetto, perché la sola rimozione del pacchetto non elimina processi persistenti o token rubati. Alcune varianti includono anche un wiper capace di cancellare la cartella personale dell’utente quando rileva la revoca del token GitHub sottratto, motivo per cui prima di ruotare le credenziali occorre isolare la macchina e neutralizzare i componenti malevoli. Vanno infine rivisti i permessi di workflow e token di pubblicazione, verificate le dipendenze npm e applicato il principio del privilegio minimo, trattando le configurazioni eseguibili dei progetti sconosciuti con la stessa cautela riservata agli script scaricati da Internet.
Fonte: TecnoAndroid