TL; DR
I pacchetti npm dannosi non sono un evento occasionale. Si tratta di un'attività di pubblicazione continua e l'elenco dei casi confermati viene aggiornato ogni settimana. Nel corso di sette edizioni consecutive del nostro Malicious Code Digest, giunta ormai all'87esima, Xygeni ha confermato 635 pacchetti dannosi, da 13 in una settimana tranquilla a 206 in una settimana intensa. Il punto è la variazione settimanale: si tratta di una cadenza, non di un singolo episodio.
- Il problema è la cadenza. Un pacchetto è passato da zero a oltre 55 versioni in una settimana. Un altro gruppo ha pubblicato quasi 30 nomi di pacchetti in meno di tre ore. Un audit settimanale non è l'unità di misura del tempo appropriata.
- Non si presentano come CVE. Un pacchetto dannoso non rappresenta un difetto nel codice legittimo, quindi non viene emesso alcun avviso, assegnato alcun punteggio e solitamente non viene fornito alcun identificativo. Un programma progettato per sfruttare le vulnerabilità è strutturalmente cieco a questo tipo di problema.
- L'abbattimento non è protezione. I pacchetti rimangono generalmente attivi per un periodo che va da pochi minuti a qualche ora. L'installazione è avvenuta o meno in questo intervallo di tempo.
- Il rilevamento deve avvenire al momento della pubblicazione, mentre l'applicazione delle norme deve avvenire al momento dell'installazione. Qualsiasi elemento in attesa di una firma, di una CVE o di una scansione settimanale viene rilasciato dopo la build che lo ha individuato.
La lista esiste. Questo non significa essere sorvegliati.
Non c'è alcun mistero riguardo ai pacchetti npm dannosi. I casi confermati vengono pubblicati, nominati e documentati ogni settimana, incluso in Il Malicious Code Digest di Xygeni, ormai giunta alla sua ottantasettesima edizione.
Il problema non è la mancanza di informazioni, ma l'insufficiente attenzione e la mancanza di cadenza. Un elenco aggiornato settimanalmente, letto mensilmente e su cui si interviene trimestralmente, è un elenco che documenta ciò che è già accaduto a qualcuno.
Ecco come si sono svolte sette settimane, sulla base dei nostri riscontri diretti e non di un sondaggio condotto da un fornitore.
Ciò che conta non sono i totali, ma la velocità di ogni singola settimana.
La velocità è tutto l'attacco
Tre scoperte emerse in quelle settimane, ognuna delle quali rappresenta un modo diverso per eludere le verifiche.
- Inondazione di versioni. Un singolo pacchetto npm,
zevairouter, ha raggiunto più di 55 versioni confermate in una settimana, a cui se ne sono aggiunte altre dieci da un pacchetto complementare. Su PyPI,bingo-aiSono state prodotte quasi 80 versioni in circa 30 minuti. Nessun processo di revisione manuale opera a tale velocità, né tantomeno un'attività svolta di notte. - Cluster sincronizzati. Diciassette pacchetti che impersonavano i nomi dei servizi interni di PayPal sono stati pubblicati nello stesso lasso di tempo, tutti alla versione 28.0.0. Non si tratta di volume, ma di una corsa: esiste un numero di versione gonfiato per superare in classifica il pacchetto interno scritto dai vostri stessi team. Lo stesso trucco è riapparso settimane dopo con
@umschool/platformpubblicato a 999.0.0. - Perseveranza nonostante gli sforzi per abbattere gli avversari. La campagna di impersonificazione di Baileys va avanti da settimane. I nomi cambiano, le versioni si moltiplicano, la ripubblicazione continua anche dopo essere stata scoperta. Un operatore che considera le rimozioni come un costo inevitabile dell'attività, anziché un motivo per fermarsi, è un operatore che la tua revisione trimestrale non riuscirà mai a raggiungere.
E il tempo di permanenza è volutamente breve. In un caso recente, i pacchetti sono rimasti attivi per un periodo compreso tra 17 minuti e 13 ore prima di essere rimossi.
Interpretatelo come un intervallo di tempo di esposizione piuttosto che come una metrica di prestazione per il registro. Se una build è stata eseguita durante tale intervallo, la successiva rimozione non ha modificato nulla.
Perché il tuo programma di gestione delle vulnerabilità non lo rileva
Questo è il punto strutturale, ed è quello che la maggior parte dei team di sicurezza non ha ancora interiorizzato.
Una vulnerabilità è un difetto nel codice scritto in buona fede da qualcuno. Un pacchetto dannoso è un artefatto deliberatamente pubblicato da un aggressore, solitamente senza identificativo, senza avviso e con una durata di vita misurata in ore. Ogni processo basato sull'acquisizione di CVE, sulla valutazione della gravità e sulle finestre di applicazione delle patch è stato progettato per il primo caso e applicato di default anche al secondo.
L'assenza di un identificatore non è una svista nel sistema CVE. È la categoria che funziona come previsto: nessuno segnala un artefatto il cui unico scopo era dannoso e, quando qualcuno potrebbe farlo, il pacchetto è sparito. Il che significa che la domanda "ha una vulnerabilità CVE?" restituisce la stessa risposta sia per un pacchetto pulito che per un programma di furto di credenziali pubblicato un'ora fa.
Cosa fanno effettivamente i carichi utili adesso
L'immagine ingenua che si ha dei pacchetti npm dannosi è quella di un programma di mining di criptovalute. La realtà attuale è che si tratta di furto di credenziali mirato agli sviluppatori e, sempre più spesso, alle credenziali delle IA presenti sui loro computer.
Migliori PhantomSync Un cluster di otto pacchetti npm pubblicati sotto un unico account ha funzionato esattamente come previsto, nascondendo un dropper auto-attivante che si è attivato circa 37 secondi dopo l'importazione, decodificato un payload simulato come un finto test fixture, installato la persistenza multipiattaforma e lanciato un programma per il furto di wallet e segreti. Ritardare, mascherare, persistere, esfiltrare.
Su scala più ampia, l'onda CHAINDROP dell' Verme Shai-Hulud ha raggiunto più di 400 pacchetti e 1,700 versioni all'inizio di agosto 2026, con un totale di 1.3 miliardi di download mensili. Il suo raccoglitore ha scansionato più di 300 modelli di credenziali, tra cui chiavi OpenAI, Anthropic e Cursor. Le macchine degli sviluppatori sono diventate preziose precisely a causa delle credenziali del modello che vi sono in possesso.
Le convenzioni di denominazione hanno seguito il denaro. I cluster più recenti imitano SDK per criptovalute e DeFi, moduli di pagamento, librerie API di WhatsApp, utility AWS e, in un caso, un pacchetto che porta apertamente il nome di uno strumento utilizzato dagli hacker per attacchi dark-LLM.
Cosa impedisce realmente i pacchetti npm dannosi?
Quattro controlli, nell'ordine in cui risultano efficaci.
1. Rilevamento al momento della pubblicazione, non al momento della divulgazione. Avviso di prevenzione malware di Xygeni Analizza i pacchetti appena pubblicati su npm, PyPI, Maven e altri registri nel momento stesso in cui appaiono, utilizzando l'analisi comportamentale e delle anomalie anziché attendere una firma o una segnalazione. Questo è l'unico punto della cronologia che precede la tua build.
2. Applicazione delle norme nel luogo in cui avviene l'installazione. Il rilevamento indica che un pacchetto è dannoso. Una policy che blocca l'installazione è ciò che impedisce l'esecuzione dello script post-installazione. Questo è ancora più importante ora che gli agenti installano le dipendenze senza che un utente le selezioni.
3. File di blocco e pinning dell'hash. Usa il npm ci in CI piuttosto che npm install, quindi viene compilato l'esatto albero delle dipendenze presente nel file di blocco. Questo chiude il percorso di sostituzione su cui si basano i typosquat e le versioni gonfiate.
4. Risultati raccolti in un unico luogo. I risultati relativi al malware appartengono alla stessa coda prioritaria del tuo SCA e i risultati del codice, non in un feed separato che qualcuno scorre velocemente. Una dipendenza dannosa confermata dovrebbe avere la precedenza su una CVE di media gravità, e solo un modello di rischio condiviso rende possibile tale confronto.
Monitora la lista o automatizza il processo.
Nessuno ha la pazienza di leggere ogni settimana il feed delle liste nozze. Ecco perché automatizzare il processo è fondamentale.
Xygeni analizza i pacchetti appena pubblicati su npm e altri registri al momento della pubblicazione, segnala i malware confermati prima che raggiungano una build e inserisce la scoperta nella stessa coda prioritaria di tutto il resto su cui i tuoi team lavorano già. Rilevamento di malware è incluso nel piano gratuito per sviluppatori, cosa che non avviene per la maggior parte dei piani gratuiti in questa categoria.
Inizia gratiso leggi Il riepilogo settimanale dei codici dannosi prima.
FAQ
Cosa sono i pacchetti npm dannosi?
Pacchetti pubblicati nel registro npm creati appositamente per causare danni: ladri di credenziali e portafogli, backdoor, dropper e artefatti che creano confusione tra le dipendenze, impersonando nomi di pacchetti interni o popolari.
Quanto sono diffusi i pacchetti npm dannosi?
Continuamente. Nelle sette edizioni recenti del nostro Malicious Code Digest, Xygeni ha confermato 635 pacchetti dannosi, da circa una dozzina in una settimana tranquilla a oltre 200 durante le campagne attive. npm rappresenta la stragrande maggioranza.
Per quanto tempo rimangono disponibili i pacchetti npm dannosi?
Spesso da pochi minuti a qualche ora. È proprio questo intervallo di tempo che conta, perché una build in esecuzione al suo interno risulta già compromessa, indipendentemente dalla velocità con cui il pacchetto viene rimosso successivamente.
I pacchetti npm dannosi ricevono vulnerabilità CVE?
Di solito no. Si tratta di artefatti pubblicati dagli hacker, non di difetti nel codice legittimo, e le campagne del 2026 monitorate non hanno ricevuto alcuna assegnazione CVE durante il periodo di sfruttamento attivo.
Come faccio a verificare se un pacchetto è dannoso prima di installarlo?
Utilizza uno strumento che analizzi i pacchetti al momento della pubblicazione anziché uno che controlli un elenco di pacchetti noti come dannosi, verifica l'editore e la cronologia delle versioni, diffida di numeri di versione insolitamente elevati e di account appena creati e applica una policy al momento dell'installazione anziché affidarti alla revisione.
Che cos'è la confusione di dipendenza?
Pubblicare un pacchetto pubblico con lo stesso nome di un pacchetto interno, solitamente con una versione maggiorata, in modo che il resolver preferisca la copia dell'attaccante. Il cluster con il nome PayPal alla versione 28.0.0 è un esempio da manuale.
