In questo articolo Indice dei contenuti 3 sezioni
Un pacchetto apparentemente innocuo, scaricato due milioni di volte a settimana, si è rivelato il centro di una campagna di malware npm che aggira le difese più recenti dell’ecosistema open source. Si chiama indexed-btree e imita una libreria legittima molto usata, sorted-btree, con un trucco semplice quanto efficace: niente codice malevolo negli script di installazione, tutto spostato nel comportamento normale della libreria a runtime. I ricercatori di Checkmarx che lo hanno individuato descrivono un’operazione curata nei dettagli, con tanto di repository GitHub costruito ad arte per sembrare un progetto serio.
Il dato che colpisce di più è proprio la diffusione. Due milioni di download settimanali non sono numeri da esperimento amatoriale, e la stessa analisi segnala un wallet collegato agli operatori che contiene 109 ETH. Nel rapporto non si afferma che quei fondi provengano da furti di criptovalute, ma la cifra dà l’idea delle dimensioni dell’operazione.
Perché le nuove protezioni di npm non sono bastate
A giugno 2026 GitHub aveva annunciato una serie di misure di sicurezza pensate proprio per frenare gli attacchi alla supply chain, quelli che dalla fine del 2025 hanno colpito ripetutamente il mondo open source. Il punto centrale era bloccare gli script di lifecycle delle dipendenze, quindi preinstall, install e postinstall, a meno di un’approvazione esplicita. Altre regole impediscono a npm di scaricare automaticamente dipendenze da repository Git o da URL remoti senza permesso.
Sulla carta, una barriera solida. Il problema è che indexed-btree non usa affatto gli script di installazione. Il loader è nascosto dentro il metodo BTree.prototype.set(), cioè una delle funzioni che qualunque sviluppatore richiama di continuo mentre l’applicazione gira. Il codice si attiva soltanto quando quel metodo viene chiamato con un valore di chiave specifico. Risultato: l’installazione sembra pulita, non scatta nessuno dei meccanismi di approvazione introdotti con npm v12, e i controlli statici passano oltre senza accorgersi di nulla.
Dall’analisi di Checkmarx emerge che l’esecuzione richiama sharedLoad.min.js, file che contiene il primo stadio offuscato del malware. Una tecnica descritta come costruita bene, capace di eludere gli strumenti standard di taint analysis e buona parte degli scanner statici.
Cosa fa il codice una volta attivo
Quando entra in azione, il codice malevolo raccoglie informazioni sul sistema: architettura, hostname, CPU, memoria, uptime. I dati vengono poi esfiltrati attraverso canali Slack e Telegram già codificati dentro il malware stesso.
C’è poi la parte più insolita. Per ricevere istruzioni, il malware interroga uno smart contract Ethereum sulla rete di test Sepolia, usato come canale di comando e controllo. Attraverso uno scambio di chiavi X25519 viene ricavata una chiave AES, che serve a decifrare il payload di secondo stadio conservato nel contratto. Quando gli operatori decidono di chiudere l’attacco, il malware può cancellare i propri file e rimuovere il trigger dal codice del pacchetto, ripulendo le tracce dietro di sé.
Sul fronte della credibilità apparente, gli autori hanno lavorato parecchio: repository GitHub dall’aspetto legittimo, cronologia dei commit riempita per simulare uno sviluppo reale, account sviluppatore curato nei dettagli.
Gli altri nove pacchetti coinvolti
L’indagine ha portato alla luce altri nove pacchetti npm legati alla stessa operazione, ormai rimossi dal registro. Anche questi con numeri di download tutt’altro che marginali: ordered-kv-index con 448.184 download, btree-leaderboard con 493.685, priority-slot-queue con 402.860, btree-range-store con 468.092, btree-core con 1.951.274, btree-time-index con 425.312, btree-lru-cache con 372.185, neighbor-key-map con 366.019 e sliding-score-window con 448.024.
Il consiglio rivolto agli sviluppatori è di non affidarsi soltanto alla scansione al momento dell’installazione, ma di affiancare un’analisi comportamentale a runtime. Chi ha installato indexed-btree o uno qualsiasi dei pacchetti elencati dovrebbe ruotare tutti i segreti e ripristinare l’ambiente di sviluppo partendo da un backup sicuro.
Fonte: TecnoAndroid
