Worm testmetest: payload da 13 MB in 42 repository GitHub

La campagna npm chiamata testmetest, che sembrava un semplice collaudo senza vittime, aveva in realtà già armato 42 repository GitHub reali di 11 proprietari. Lo ha documentato JFrog Security Research in un rapporto del 26 ottobre, ripreso da The Register e da CSO Online. Il dettaglio che rende la campagna difficile da trovare: i file con il payload pesano tra 12,9 e 13,7 MB, oltre i limiti della ricerca del codice e delle API dei contenuti di GitHub. Anche heise Security ha dato la notizia, ma il suo testo non era disponibile per questa analisi.

Pochi giorni fa abbiamo raccontato Gheist, che con token GitHub rubati estrae i segreti dai log di Actions. testmetest è una campagna diversa: un worm che si propaga attraverso npm, ruba credenziali e si nasconde dentro i repository delle vittime.

Dal «test» alle vittime reali

Secondo The Register, la società SafeDep ha individuato per prima la campagna, con 18 pacchetti npm pubblicati dallo stesso operatore tra il 19 e il 25 ottobre. Nell’analisi del 22 ottobre, che decodificava event-bus-lite-testmetest@0.0.1, SafeDep non aveva trovato pacchetti di terzi compromessi: tutta l’attività sembrava provenire dagli account di prova dell’operatore. SafeDep collegava il payload alla famiglia Miasma, segnalando però incertezza sull’origine. The Register riporta che il codice è in comune con il worm Miasma Phantom Gyp di giugno e aggiunge il wiper di Mini Shai-Hulud, che cancella la cartella home della vittima quando questa revoca il token GitHub rubato.

JFrog, i cui sistemi avevano segnalato pacchetti di tipo Shai-Hulud su npm il 21 ottobre, ha trovato invece furti di account a partire da luglio, cronologie dei commit falsificate, branch di pubblicazione di breve durata e credenziali npm esposte.

Come funziona la catena

Installazione del pacchetto npm. Secondo il rapporto citato da CSO Online, le versioni malevole usano un’espansione di comando in binding.gyp per eseguire index.js durante l’installazione, senza dichiarare uno script di installazione. Il loader applica a ogni build una trasformazione di Cesare a un array di codici carattere, decifra uno stadio AES-128-GCM e trova o scarica Bun 1.2.18; il payload viene passato a bun run - oppure scritto in una cartella temporanea .b-* cancellata dopo l’esecuzione. Il payload completo raccoglie credenziali, modifica repository e configurazioni CI e si propaga tramite i registri dei pacchetti.

Repository armati. Nei repository dirottati la campagna lascia segnaposto innocui oppure payload veri: hook di esecuzione per assistenti IA e ambienti di sviluppo (un hook SessionStart di Claude Code, impostazioni di Gemini, configurazione MCP e regole di Cursor, attività di VS Code all’apertura della cartella) e wrapper polimorfici da 12,9 a 13,7 MB che si decodificano tutti nello stesso payload nascosto. Basta aprire il progetto con uno di questi strumenti per eseguirlo. I file ci.js armati contengono publisher pensati per girare in GitHub Actions e usare token npm o il trusted publishing per pubblicare nuove versioni malevole: il ciclo si chiude.

Dimensione come camuffamento. I wrapper superano quello che la ricerca del codice di GitHub indicizza e quello che l’API dei contenuti restituisce: per questo, secondo un analista citato da CSO Online, le prime analisi avevano trovato gli hook ma ritenuto vuoti i file del payload.

Addon nativo ed elusione. Un addon compilato non contiene payload proprio: decifra a runtime un file .napi_cache. Prima di partire il loader cerca runner CI, container, sandbox e debugger e, se li trova, esce senza fare nulla. Una seconda build salta il file cifrato e scarica un loader da un repository dell’account GitHub dell’operatore, CementBeetleSteeple, che ospitava 17 repository della campagna; secondo JFrog, un repository dell’attaccante è anche un punto di raccolta attivo di dati cifrati.

Collegamento con cPanel. JFrog collega lo stesso account a uno scanner «shellpanel», già descritto da Socket in una campagna che usava GitHub Actions in repository compromessi per sfruttare CVE-2026-41940, bypass di autenticazione di cPanel e WHM (nel catalogo KEV di CISA da aprile, con versioni corrette disponibili), e rubare credenziali dei server. JFrog precisa di non aver confermato compromissioni di server cPanel derivate.

Nella nostra lettura le tecniche MITRE ATT&CK pertinenti sono T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion), T1552.001 (Credentials In Files) e T1485 (Data Destruction) per il wiper.

Impatto per le aziende europee e italiane

Il rischio riguarda chiunque sviluppi con pacchetti npm o lavori su repository GitHub di terzi: il portatile di uno sviluppatore contiene token GitHub e npm, chiavi cloud e chiavi dei fornitori di IA. Con gli hook degli assistenti IA il momento pericoloso non è più solo l’installazione, ma anche la semplice apertura di un progetto. Per i soggetti NIS2 la sicurezza della catena di fornitura del software è una misura richiesta, e l’uso di credenziali rubate su sistemi di produzione va valutato come possibile incidente da notificare.

Cosa fare subito

Indicazioni di JFrog riportate da CSO Online, salvo dove diversamente indicato:

1. Tratta come compromessa ogni macchina su cui è stata installata una versione completa del worm.
2. Prima di revocare i token (indicazione nostra): il wiper descritto da The Register si attiva alla revoca del token GitHub. Isola la macchina e metti al sicuro i dati della cartella home, poi procedi.
3. Revoca e ruota le credenziali GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes e dei fornitori di IA.
4. Controlla tutti i repository raggiungibili dalle identità colpite: .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.json, hook inattesi in composer.json o Makefile, commit con skip-checks:true. Elenca l’albero dei file direttamente: non affidarti alla ricerca del codice o all’API dei contenuti.
5. Pulisci: cancella i branch non autorizzati chore/ci-* e deps/upd-*, disattiva i workflow malevoli, rimuovi i falsi artefatti CodeQL chiamati scan-output.
6. Blocca hxxp[:]//43[.]228[.]157[.]68:80 e l’infrastruttura collegata.
7. Cerca nei log e sui runner di GitHub Actions /tmp/.svc, ipscan, riferimenti a CVE-2026-41940, richieste /api/dl/<arch> e scansioni insolitamente ampie; sulle macchine, file .napi_cache.
8. Aggiorna cPanel e WHM alle versioni corrette per CVE-2026-41940, se li usi.

Come aiuta ARXDOME

ARX Sentry raccoglie con il suo agent log, eventi, inventario dei processi e controllo dell’integrità dei file nelle cartelle stabilite, anche sulle postazioni degli sviluppatori e sui runner self-hosted. Con ARX Trace i nostri analisti possono avviare raccolte e ricerche su più macchine per cercare gli indicatori elencati, e ARX Shield permette di isolare dalla rete una macchina sospetta prima di revocare i token.

Ultimo aggiornamento: 29 ottobre 2026