Sommario
Nel marzo 2025, Sonatype ha individuato una campagna di compromissione mirata che ha coinvolto diversi pacchetti npm dedicati allo sviluppo crypto. Le versioni più recenti di questi pacchetti, pur mantenendo l’apparenza di componenti legittimi, sono state modificate per includere codice offuscato con lo scopo di rubare informazioni sensibili dagli ambienti di sviluppo degli utenti.
La gravità dell’attacco risiede nella longevità e diffusione di alcuni dei pacchetti colpiti, alcuni dei quali sono presenti nel registry npm da oltre nove anni, con migliaia di download complessivi, e impiegati per costruire interfacce tra servizi blockchain e protocolli finanziari decentralizzati.
Una minaccia invisibile nelle dipendenze: pacchetti compromessi dopo anni di inattività
Il pacchetto bnb-javascript-sdk-nobroadcast
, ad esempio, non riceveva aggiornamenti da quattro anni, ma ha improvvisamente ricevuto una nuova versione contenente codice malevolo, senza che il relativo repository GitHub venisse aggiornato. Il comportamento anomalo è stato rilevato dai sistemi automatici di Sonatype, i quali hanno analizzato la discrepanza tra il codice pubblicato su npm e quello open source pubblico, evidenziando l’inserimento di script obfuscati nel pacchetto distribuito.
Package(s) | Hijacked (malicious) version | Total downloads over lifetime (all versions) |
country-currency-map | 2.1.8 | 288,851 |
bnb-javascript-sdk-nobroadcast | 2.16.16 | 38,673 |
@bithighlander/bitcoin-cash-js-lib | 5.2.2 | 5,413 |
eslint-config-travix | 6.3.1 | 26,312 |
@crosswise-finance1/sdk-v2 | 0.1.21 | 886 |
@keepkey/device-protocol | 7.13.3 | 53,325 |
@veniceswap/uikit | 0.65.34 | 1,071 |
@veniceswap/eslint-config-pancake | 1.6.2 | 173 |
babel-preset-travix | 1.2.1 | 6,902 |
@travix/ui-themes | 1.1.5 | 5,821 |
@coinmasters/types | 4.8.16 | 61,626 |
Tra gli altri pacchetti colpiti spiccano country-currency-map
, @coinmasters/types
, eslint-config-travix
, @bithighlander/bitcoin-cash-js-lib
, babel-preset-travix
e @keepkey/device-protocol
. Alcuni di questi risultano ancora referenziati in progetti attivi, mentre altri sono considerati obsoleti, ma rimangono presenti nei workflow di build e nelle pipeline CI/CD di numerosi sviluppatori.
Script offuscati per sottrarre variabili d’ambiente e dati riservati
Il payload dannoso si attiva durante la fase di installazione del pacchetto, un comportamento altamente pericoloso per qualsiasi ambiente automatizzato. Gli script inseriti hanno lo scopo di catturare variabili d’ambiente, incluse stringhe contenenti API key, token di autenticazione, credenziali SSH e accessi cloud.

I dati esfiltrati vengono inviati a un endpoint controllato dagli attaccanti, eoi2ectd5a5tn1h.m.pipedream.net
, configurato per raccogliere i payload trasmessi da ogni sistema compromesso.
La natura offuscata del codice rende particolarmente difficile individuare il comportamento malevolo mediante una semplice analisi statica, soprattutto in ambienti dove la sicurezza della supply chain non prevede l’ispezione manuale delle dipendenze.
Nessuna modifica nei repository GitHub: l’attacco si è svolto esclusivamente su npm
Uno degli aspetti più sconcertanti riguarda l’assenza di aggiornamenti nei repository GitHub ufficiali, mentre nuove versioni dei pacchetti apparivano su npm. Questo suggerisce che l’attaccante non ha forzato un push sul repository pubblico, ma ha agito direttamente sul sistema di pubblicazione npm, probabilmente compromettendo le credenziali di mantenitori inattivi.

Secondo Sonatype, le cause più probabili includono attacchi di credential stuffing o acquisizione di domini scaduti associati agli account dei maintainer, scenari entrambi documentati dalla stessa piattaforma npm. In particolare, il fatto che più pacchetti siano stati aggiornati contemporaneamente con codice malevolo suggerisce una campagna coordinata basata sul controllo multiplo di account compromessi.
La debolezza delle misure di sicurezza nei progetti legacy
L’obbligatorietà della 2FA (autenticazione a due fattori) introdotta da npm nel 2022 riguarda solo i maintainer di pacchetti ad alto impatto, ossia quelli con oltre un milione di download settimanali o 500 progetti dipendenti. Tuttavia, molti progetti abbandonati o con pochi utenti rimangono esclusi da tale obbligo, risultando così più vulnerabili a manipolazioni silenziose.
Ti è piaciuto questo contenuto? Iscriviti alla nostra newsletter settimanale
Seguici su Google News iscrivendoti al canale
Progetti non più mantenuti attivamente, soprattutto se usati in ambienti dove non è stata eseguita una rigorosa validazione delle dipendenze, costituiscono un punto d’accesso privilegiato per gli attori malevoli, che sfruttano la fiducia implicita nel codice open source per colpire in profondità.
Il firewall Sonatype blocca automaticamente i pacchetti compromessi

Sonatype ha confermato che tutti i pacchetti malevoli individuati sono stati immediatamente bloccati dal Repository Firewall, la soluzione di difesa proattiva integrata nella sua piattaforma per la gestione del rischio nelle dipendenze open source. Questo strumento è in grado di:
- rilevare anomalie comportamentali nei pacchetti
- confrontare versioni nuove con precedenti versioni sicure
- impedire la propagazione di codice dannoso nei build aziendali
Secondo i ricercatori, questo tipo di minacce è progettato per sfuggire agli strumenti di analisi della composizione software (SCA) tradizionali, motivo per cui è essenziale dotarsi di strumenti in grado di rilevare dinamicamente codice sospetto o modifiche non documentate.
L’ennesimo allarme per la sicurezza della supply chain software
L’incidente evidenzia per l’ennesima volta come la fiducia cieca nelle dipendenze open source, se non supportata da un sistema di controllo continuo, possa diventare un vettore critico di compromissione. In un contesto dove lo sviluppo agile e la CI/CD impongono velocità e automazione, la sicurezza della supply chain deve essere implementata a livello infrastrutturale, con strumenti capaci di agire prima ancora che il codice venga compilato o testato.
Gli sviluppatori, i DevOps e i team di sicurezza devono rivalutare le policy di aggiornamento automatico, ridurre le dipendenze non necessarie e monitorare in tempo reale le versioni delle librerie open source utilizzate nei propri progetti, soprattutto quando coinvolgono componenti di ambito crittografico o finanziario.