Il pacchetto npm indexed-btree elude le difese install-time con payload runtime

Il 20 settembre 2026 Checkmarx ha reso pubblica l'analisi di una campagna su npm che sfrutta una tecnica di evasione mai documentata in precedenza: il payload malevolo è incastonato nel metodo BTree.prototype.set() di una libreria che impersona il pacchetto legittimo sorted-btree, con quasi 2 milioni di download settimanali. L'esecuzione avviene a runtime, quando l'applicazione chiama il metodo, non durante l'installazione: questo rende inutili i meccanismi di approvazione introdotti da GitHub in npm v12 a giugno 2026 per bloccare script preinstall, install e postinstall.

Come funziona l'evasione: dal metodo set() al C2 su Ethereum

La tecnica si distacca nettamente dalle evasioni precedenti su npm. Secondo quanto documentato da Checkmarx e riportato da BleepingComputer, il malware non ricorre a hook del lifecycle di installazione — preinstall, install, postinstall, binding.gyp — ma si annida nel metodo centrale della libreria stessa. "The malware loader hides inside the library's own BTree.prototype.set method, which is the main function that every user would call constantly", riportano i ricercatori Checkmarx via BleepingComputer.

Quando il metodo viene invocato con una chiave specifica, si attiva la catena di esecuzione. Il primo stadio è contenuto in sharedLoad.min.js, offuscato. I ricercatori Checkmarx lo descrivono come "a well-built way to sneak past standard taint-analysis tools and most static scanners". Questo significa che scanner statici e strumenti di analisi del flusso dati tipicamente impiegati per il controllo delle dipendenze npm non rilevano l'anomalia, perché il codice non presenta pattern sospetti in fase di installazione.

Dopo l'attivazione, il malware raccoglie informazioni di sistema: architettura, hostname, CPU, memoria disponibile, uptime. L'esfiltrazione avviene attraverso canali Slack e Telegram hardcoded nel payload. Il comando e controllo, invece, passa per uno smart contract Ethereum sulla rete di test Sepolia, con scambio chiavi X25519 e decrittazione AES. Gli attacchi non esfiltrano dati sensibili direttamente sulla blockchain: il contratto funge da meccanismo di orchestrazione, sfruttando la decentralizzazione per rendere più complessa la presa di down del C2.

Perché le difese npm v12 non rilevano il payload

A giugno 2026 GitHub ha introdotto in npm v12 meccanismi di approvazione obbligatoria per gli script di installazione: qualsiasi pacchetto che esegua codice nelle fasi preinstall, install o postinstall richiede ora conferma esplicita dell'utente o dell'amministratore. La campagna indexed-btree dimostra i limiti architetturali di questo approccio. "As a result, installation appears clean and triggers none of npm v12's approval mechanisms", riporta BleepingComputer sintetizzando l'analisi Checkmarx.

La distinzione è netta: npm v12 controlla il lifecycle dell'installazione, non l'esecuzione del codice dell'applicazione. Quando un'applicazione importa una libreria e ne chiama i metodi, il runtime Node.js non applica sandbox o approvazioni. L'attaccante ha semplicemente spostato il punto di innesco dal momento dell'installazione al momento dell'uso, sfruttando una proprietà intrinseca dell'ecosistema: le librerie sono fatte per essere eseguite.

OffSeq Radar conferma la natura dell'evasione: "embedding malicious code in the package's runtime behavior instead of installation scripts". Questa formulazione, convergente con la fonte primaria Checkmarx, sottolinea che la tecnica non sfrutta una vulnerabilità di npm v12, ma la sua cecità progettuale verso il comportamento post-installazione.

"This evasion technique undermines supply chain security measures that rely on detecting malicious install scripts" — OffSeq Radar

La catena di distribuzione: repository finti e nove pacchetti satellite

Gli operatori hanno costruito un repository GitHub con cronologia commit curata per apparire legittimo. Questo elemento non è decorativo: in un ecosistema dove la verifica sociale — stelle, fork, attività recente — influenza le decisioni di adozione, la credibilità superficiale del repository abbassa le difese percettive degli sviluppatori.

Checkmarx ha scoperto nove pacchetti npm aggiuntivi collegati alla stessa operazione. Tali pacchetti sono stati rimossi dal registro npm, ma la fonte non ne specifica i nomi. Non è documentato se condividano la stessa tecnica runtime o adottino varianti. Questo limite impedisce di tracciare l'estensione esatta della campagna oltre il pacchetto principale.

Il wallet Ethereum degli attaccanti contiene 109 ETH al momento della rilevazione. Il report Checkmarx non afferma che tali fondi derivino da furto di criptovalute o riscatti: potrebbero essere fondi di provisioning per il C2, ricavi di attività collaterali, o semplicemente capitali preesistenti. La fonte non chiarifica l'origine.

Perché è importante

Il caso indexed-btree non è un'anomalia isolata: è la terza generazione di evasioni npm documentata nel 2026, dopo le campagne ChainDrop (preinstall worm, Microsoft e StepSecurity, agosto 2026) e Shai-Hulud (binding.gyp evasion, Morphisec). Ciascuna ha reagito a un hardening specifico, spostando l'attacco su un vettore adiacente. ChainDrop ha aggirato la vigilanza sui preinstall con propagazione worm; Shai-Hulud ha sfruttato il processo di build nativo; indexed-btree ha abbandonato del tutto il lifecycle di installazione.

Il dossier non documenta misure correttive specifiche rilasciate da npm o GitHub oltre alla rimozione dei pacchetti. Non è confermata l'esistenza di un CVE dedicato a questa campagna: il CVE-2026-27960 presente nelle fonti NVD riguarda una privilege escalation in OpenCTI, non npm. La data di inizio effettivo della campagna non è nota. Non è specificato come avvenga esattamente il trigger tramite chiave nel metodo set(), né se esistano indicatori di compromissione pubblicati per la rilevazione retroattiva.

Il limite più rilevante per chi gestisce pipeline software è che nessuna delle difese attuali — scanner install-time, approvazione script, analisi statica del manifest — avrebbe rilevato questo payload. Il codice malevolo non è nel package.json, non è in un hook, non è in un binario precompilato: è nel metodo stesso della libreria, indistinguibile da codice funzionale fino all'invocazione con la chiave attivatrice.

L'ecosistema npm ha ora un problema di fondo: ogni barriera install-time incentiva gli attaccanti a nascondersi più a fondo, dove i controlli non arrivano. Le difese devono spostarsi a valle, verso l'analisi comportamentale runtime e il monitoraggio delle chiamate di rete in ambiente di esecuzione, ma il brief non documenta strumenti o framework disponibili per questa transizione.

Fonti

• https://www.bleepingcomputer.com/news/security/malicious-npm-packages-evade-install-script-defenses-at-runtime/
• https://radar.offseq.com/threat/malicious-npm-packages-evade-install-script-defenses-at-runtime-bd6632abcdaf0649
• https://nvd.nist.gov/vuln
• https://nvd.nist.gov/vuln/detail/cve-2026-27960
• https://www.stepsecurity.io/blog/chaindrop-npm-worm
• https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/
• https://www.morphisec.com/blog/its-in-your-ai-assistant-now-shai-hulud-wave-3-and-the-miasma-worm-targeting-npm/
• https://nvd.nist.gov/vuln/search
• https://nvd.nist.gov/vuln/weaknesses
• https://nvd.nist.gov/vuln/data-feeds

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti