TLDR
- JFrog ha analizzato un cluster di pacchetti npm malevoli che imitano tool Rollup legittimi.
- Il trucco non è il typosquatting grossolano: i pacchetti copiano metadata, README e forma del progetto vero.
- Il rischio è alto perché plugin e dipendenze di build girano su workstation e CI con token, chiavi e segreti.
- La difesa passa da review della dependency tree, lockfile, egress control, CI isolata e rotazione credenziali se un pacchetto sospetto è stato installato.
Perché conta ora
La supply chain JavaScript non si rompe solo quando un pacchetto famoso viene compromesso.
A volte basta un pacchetto piccolo, pubblicato con un nome plausibile, infilato nella stessa area semantica di uno strumento reale. Non deve sembrare perfetto. Deve sembrare abbastanza normale da sopravvivere a una review fatta di fretta.
JFrog ha documentato a fine giugno 2026 un cluster di pacchetti npm malevoli collegati a campagne attribuite a Lazarus. Il punto interessante è la maschera: pacchetti che imitano tooling Rollup, con nomi vicini, metadata credibili e codice apparentemente coerente con il mondo dei polyfill.
Non è il vecchio errore da tastiera.
È imitazione di contesto.
Il pacchetto non deve essere famoso
Molti sviluppatori controllano un nome solo quando sembra strano.
Se un pacchetto contiene parole come rollup, polyfill, core, node, svg o plugin, dentro una build JavaScript può sembrare al suo posto. Soprattutto se il README è copiato bene, se il repository punta a un progetto noto e se il codice iniziale fa davvero qualcosa di credibile.
Questo è il trucco: non chiedere fiducia assoluta.
Chiedere una distrazione.
Il pacchetto malevolo può apparire come un componente laterale, una dipendenza temporanea, una utility innocua. E una volta installato, il confine è già stato spostato.
Perché la build è un bersaglio perfetto
La build è un posto privilegiato.
Un ambiente di sviluppo o CI può avere:
- token npm;
- chiavi SSH;
- credenziali Git;
- variabili cloud;
- accessi a registry privati;
- sorgenti non pubblici;
- file
.env; - configurazioni Docker;
- history della shell;
- cache dei browser o tool di AI coding;
- permessi di pubblicazione o deploy.
Un pacchetto installato lì non è solo codice in più.
È codice dentro la stanza dove tieni le chiavi.
Il pattern a strati
La campagna analizzata da JFrog usa più livelli.
Il primo pacchetto sembra un plugin o una utility Rollup. Poi installa o carica un secondo pacchetto. Il secondo pacchetto sembra un tool SVG. Poi recupera codice remoto e lo esegue. Solo seguendo tutta la catena emerge il comportamento reale: controllo remoto, raccolta file, furto di dati browser e wallet, lettura clipboard, ricerca di configurazioni da sviluppatore.
Visto a pezzi, ogni livello può sembrare meno grave.
Visto intero, è una workstation trasformata in fonte di segreti.
Questo è il motivo per cui guardare solo package.json non basta. Devi guardare anche ciò che entra dopo.
Cosa controllare
Quando compare una nuova dipendenza di build:
- Nome del pacchetto e somiglianza con progetti reali.
- Età del pacchetto.
- Maintainer e storico pubblicazioni.
- Repository indicato nei metadata.
- Differenza tra repository e contenuto pubblicato su npm.
- Script di installazione, postinstall e prepare.
- Dipendenze transitive appena pubblicate.
- Lockfile modificato.
- Richieste di rete durante installazione o import.
- Accesso a file utente, browser, wallet, cloud e SSH.
La review buona non chiede solo "questo nome mi sembra giusto?".
Chiede "perché questa cosa deve girare nel mio ambiente di build?".
Difese pratiche
Per un team piccolo:
- blocca l'aggiunta di dipendenze senza review;
- controlla sempre il lockfile;
- usa runner CI usa-e-getta;
- separa i token di build dai token di deploy;
- evita token npm o cloud permanenti nei runner;
- limita il traffico in uscita durante install e build;
- usa dependency scanning e policy su pacchetti appena pubblicati;
- preferisci versioni fissate e aggiornamenti espliciti;
- rimuovi segreti dalle workstation di sviluppo quando non servono;
- ruota credenziali dopo installazioni sospette.
Per progetti più maturi, vale la pena aggiungere provenance, firma degli artefatti e una allowlist dei registry o dei namespace consentiti.
Non perché risolvano tutto.
Perché alzano il costo della distrazione.
Errori comuni
Il primo errore è fidarsi del nome.
Un nome che sembra tecnico non è una garanzia.
Il secondo errore è credere che un pacchetto malevolo debba essere palesemente brutto. Le campagne moderne copiano forma, descrizioni, repository e abitudini dell'ecosistema che imitano.
Il terzo errore è trattare la CI come sterile. Un runner può essere effimero e comunque vedere segreti preziosi nel momento peggiore.
Dopo il sospetto
Se hai installato uno dei pacchetti indicati negli IoC della campagna o una dipendenza simile:
- rimuovi il pacchetto dal progetto;
- rigenera il lockfile dopo aver verificato le dipendenze;
- cerca processi e file temporanei creati da Node;
- controlla traffico in uscita dai runner;
- considera compromesse le credenziali disponibili durante build e install;
- ruota token npm, GitHub, cloud, SSH e registry;
- controlla accessi anomali successivi all'installazione;
- ricostruisci runner e workstation se l'esecuzione è avvenuta fuori sandbox.
Non basta cancellare node_modules.
Il problema non è la cartella.
È quello che il pacchetto ha potuto vedere mentre era vivo.
Il punto
La supply chain non è una lista di nomi.
È una catena di fiducia operativa.
Se un pacchetto gira nella build, eredita un pezzo del tuo progetto, della tua identità e dei tuoi segreti. I pacchetti npm finti funzionano perché non sembrano invasori. Sembrano arredamento tecnico.
E in una stanza piena di chiavi, anche l'arredamento va controllato.
FAQ
Che cosa sono i pacchetti npm finti?
Sono pacchetti pubblicati con nomi, descrizioni o metadata simili a progetti legittimi, pensati per essere installati per errore o per sembrare plausibili durante una review veloce.
Perché i pacchetti Rollup sono interessanti per un attaccante?
Perché i plugin di build vengono caricati da configurazioni locali e pipeline CI. In quei contesti possono trovare sorgenti, token npm, chiavi Git, variabili cloud e altri segreti.
npm audit basta?
No. npm audit è utile per vulnerabilità note, ma non garantisce che un pacchetto appena pubblicato o malevolo venga bloccato in tempo.
Cosa controllare dopo un'installazione sospetta?
Dipendenze dirette e transitive, lockfile, processi node anomali, file temporanei, traffico in uscita, cronologia shell e soprattutto token usati dalla macchina o dal runner CI.
Come ridurre il rischio in CI?
Usare token minimi e temporanei, bloccare installazioni non approvate, separare build da segreti di deploy, limitare egress e usare ambienti usa-e-getta.