- Cosa è successo nell'attacco a Axios su npm
- Come una singola riga nel file package.json è diventata il vettore di attacco
- Perché la revisione tradizionale del codice non ha individuato l'attacco ad Axios
- Perché il raggio d'azione dell'esplosione copre tutto ciò che il pacco tocca
- Quali misure di sicurezza avrebbero potuto cambiare l'esito
- Scopri di più sullaSupply Chain Software
- Domande frequenti
Il dirottamento dei pacchetti npm è un attacco alla catena di approvvigionamento del software che sfrutta la fiducia riposta in un pacchetto come via d'accesso. Gli autori degli attacchi non hanno bisogno di modificare il codice del repository se riescono a controllare l'account che pubblica il pacchetto.
È proprio questo che rende i pacchetti npm affidabili una superficie di attacco così vulnerabile. Quando l'account di un manutentore viene compromesso, ogni progetto che installa il pacchetto interessato può essere esposto a rischi attraverso un normale aggiornamento delle dipendenze. L'incidente di Axios del marzo 2026 ha dimostrato come un solo account npm compromesso potesse mettere a rischio oltre 100 milioni di download settimanali senza modificare in modo visibile il codice sorgente di Axios.
Comprendere come funziona il dirottamento dei pacchetti npm aiuta i team di sicurezza a mettere a punto misure di controllo che affrontino il percorso di attacco effettivo, anziché limitarsi ai file sorgente che la maggior parte dei team esamina.
Cosa è successo nell'attacco a Axios su npm
L'attacco a Axios su npm è consistito nell'appropriazione dell'account di un manutentore, che ha trasformato un pacchetto affidabile in un veicolo per la diffusione di malware. L'autore dell'attacco ha compromesso l'account npm del manutentore principale di Axios, ha modificato l'indirizzo e-mail registrato sostituendolo con uno controllato dall'autore stesso e ha impedito l'accesso al manutentore legittimo.
L'operazione è stata pianificata e condotta con cura. Circa 18 ore prima dell'attivazione del codice dannoso è stato pubblicato un pacchetto esca, che ha generato una cronologia di pubblicazioni senza destare sospetti immediati. Successivamente, nell'arco di circa 39 minuti, l'autore dell'attacco ha distribuito due versioni dannose: axios 1.14.1 per il ramo delle versioni moderne e axios 0.30.4 per il ramo legacy.
Entrambe le linee di rilascio sono state lanciate contemporaneamente per massimizzare la visibilità. Questa scelta ha aumentato la probabilità che sia gli ambienti attuali che quelli preesistenti scaricassero un pacchetto compromesso attraverso la normale procedura di aggiornamento.
Come una singola riga nel file package.json è diventata il vettore di attacco
Una singola modifica alle dipendenze nel file `package.json` può costituire l'intero percorso di attacco in un attacco alla catena di approvvigionamento di npm. Nell'incidente relativo ad Axios, non è stato necessario modificare alcun file sorgente di Axios, poiché il comportamento dannoso è stato introdotto tramite una nuova dipendenza.
Tale dipendenza veniva eseguita tramite un hook post-installazione di npm. Non appena una workstation di uno sviluppatore, una pipeline CI/CD o un sistema di compilazione eseguiva il comando `npm install`, il pacchetto dannoso poteva contattare un server controllato dall'autore dell'attacco, recuperare un payload specifico per il sistema operativo e avviare l'esecuzione.
I payload sono stati preparati per macOS, Windows e Linux. L'attacco era multipiattaforma per sua stessa natura. Una volta eseguito, il dropper ha cancellato ogni traccia della propria presenza e ha sostituito il file package.json originale con una versione contraffatta, rendendo molto più difficile un'eventuale analisi forense successiva.
Perché la revisione tradizionale del codice non ha individuato l'attacco ad Axios
La revisione tradizionale del codice è pensata per controllare le modifiche al codice sorgente all'interno di un repository, ma questa vulnerabilità non risiedeva nel codice sorgente di Axios. L'attacco a Axios non si basava su modifiche visibili nel repository, poiché la logica dannosa risiedeva in una dipendenza separata piuttosto che nel codice sorgente di Axios.
Questa differenza è importante. Un revisore che esamini l'aggiornamento del pacchetto vedrebbe poco più di una nuova riga relativa alle dipendenze nel file package.json. Il comportamento dannoso effettivo si manifestava solo dopo che la dipendenza era stata risolta e installata.
Ecco perché gli attacchi basati su pacchetti affidabili sono difficili da individuare ricorrendo esclusivamente alla revisione tramite diff. Il percorso di attacco si trova al di fuori dei file sorgente che la maggior parte dei team esamina, anche se il pacchetto appare comunque sufficientemente legittimo da superare i normali flussi di lavoro di sviluppo.
Perché il raggio d'azione dell'esplosione copre tutto ciò che il pacco tocca
L'ambito di impatto di un pacchetto npm compromesso non è il pacchetto stesso. L'ambito di impatto è tutto ciò con cui il pacchetto entra in contatto.
Per la maggior parte delle organizzazioni, ciò comprende pipeline CI/CD con autorizzazioni elevate, endpoint degli sviluppatori con chiavi SSH e token cloud, server di compilazione con accesso in scrittura ai repository degli artefatti e strumenti di distribuzione collegati ai sistemi di produzione. Un pacchetto dannoso non ha bisogno di rimanere all'interno dell'albero delle dipendenze per causare danni. È sufficiente un solo punto di esecuzione considerato affidabile.
Ecco perché l'incidente di Axios va ben oltre la gestione dei pacchetti JavaScript. Una compromissione avvenuta dopo l'installazione può trasformare una normale installazione in un furto di credenziali, in un movimento laterale o in un accesso all'infrastruttura a valle.
Le vulnerabilità strutturali messe in luce dall'attacco ad Axios
L'incidente di Axios ha messo in luce delle debolezze strutturali che sono comuni negli odierni ambienti di sviluppo software. Non si tratta di casi isolati e rari, bensì di presupposti normali in molte organizzazioni.
Fiducia nell'identità dei responsabili della manutenzione dei pacchetti
La fiducia nei pacchetti npm è spesso legata all'account del manutentore che pubblica il pacchetto. Se tale account viene violato o è vittima di un attacco di phishing, l'autore dell'attacco acquisisce la stessa autorità di pubblicazione del manutentore legittimo.
Versioni delle dipendenze variabili
Le versioni con impostazioni variabili o fissate in modo approssimativo aumentano l'esposizione a versioni dannose. Una versione compromessa appena pubblicata può entrare automaticamente in un ambiente senza che sia necessaria un'approvazione deliberata.
Script post-installazione non monitorati
Gli script post-installazione di npm possono eseguire codice arbitrario con i permessi del processo di installazione. Molte organizzazioni non controllano né limitano gli script del ciclo di vita prima della loro esecuzione.
Pipeline CI/CD con visibilità limitata sull'esecuzione
Le pipeline CI/CD dispongono spesso di ampi diritti di accesso ai sistemi interni, all'infrastruttura di compilazione e agli ambienti cloud. Tali pipeline vengono spesso considerate affidabili per impostazione predefinita e raramente vengono monitorate per individuare eventuali comportamenti dannosi dei pacchetti al momento dell'installazione.
Endpoint degli sviluppatori non coperti dalla protezione completa
I computer degli sviluppatori ospitano risorse di grande valore, tra cui chiavi SSH, credenziali cloud e token aziendali. Gli endpoint degli sviluppatori sono inoltre bersagli frequenti degli attacchi, poiché spesso presentano una minore visibilità e controlli di runtime più limitati rispetto ai sistemi di produzione.
Archivi di credenziali senza trigger di rotazione rapida
Un attacco alla catena di fornitura del software spesso si traduce in una fuga di credenziali. Molti team non dispongono ancora di flussi di lavoro affidabili in grado di identificare le informazioni riservate potenzialmente a rischio e di sostituirle immediatamente.
Quali misure di sicurezza avrebbero potuto cambiare l'esito
Tre categorie di controlli di sicurezza avrebbero ridotto in modo significativo l'impatto dell'attacco ad Axios. Ciascun controllo agisce su un punto diverso della catena di attacco: l'esecuzione dei pacchetti, l'esposizione delle credenziali e la visibilità delle dipendenze.
1. Scansione alla ricerca di malware a livello di pacchetto prima dell'installazione
La scansione dei pacchetti alla ricerca di malware aiuta a bloccare le dipendenze dannose prima che vengano eseguite. Questo è fondamentale nel caso degli attacchi npm, poiché gli hook post-installazione vengono eseguiti durante l'installazione, lasciando poco tempo per una verifica manuale una volta scaricato il pacchetto.
L'analisi dei pacchetti, delle dipendenze e degli script relativi al ciclo di vita prima dell'installazione consente di individuare malware noti, comportamenti sospetti, vulnerabilità e credenziali hardcoded prima che il pacchetto raggiunga l'endpoint di uno sviluppatore o un ambiente CI/CD.
MetaDefender Software Supply Chain è la soluzione di sicurezza della catena di fornitura del software OPSWATper la convalida di componenti software, fornitori e pipeline di compilazione. Utilizza il rilevamento delle minacce multi-motore, inclusa la scansione multipla Metascan su oltre 30 motori antivirus, per ispezionare i pacchetti alla ricerca di malware, vulnerabilità e segreti hardcoded prima che entrino nel ciclo di vita dello sviluppo.
2. Gestione proattiva dei segreti con trigger di rotazione
Una gestione proattiva dei segreti riduce il valore di una violazione riuscita. Quando viene individuato un pacchetto sospetto, i team devono disporre di una procedura di risposta che consideri le credenziali locali, le chiavi SSH, i token e i segreti della pipeline come potenzialmente compromessi e provveda a sostituirli rapidamente.
Il rilevamento dei segreti hardcoded contribuisce allo stesso obiettivo. Un pacchetto dannoso può sottrarre segreti dalla memoria o dal disco, ma i segreti esposti già presenti nel codice o nelle dipendenze aggiungono un ulteriore livello di rischio che è possibile prevenire.
3. Supply Chain e monitoraggio delle dipendenze
La visibilità sulla catena di fornitura aiuta i team a individuare modifiche impreviste ai pacchetti prima che tali modifiche si traducano in problemi a valle. I team di sicurezza devono sapere quali pacchetti sono installati, quali versioni sono bloccate, quali nuove dipendenze sono state aggiunte e dove vengono eseguiti tali componenti.
Senza un adeguato monitoraggio e una visione d'insieme delle dipendenze, il primo segnale di una violazione potrebbe essere l'uso improprio delle credenziali o l'uso improprio dell'infrastruttura, quando l'evento di installazione originario è ormai lontano nel tempo.
Scopri di più sullaSupply Chain Software
La sicurezza della catena Software dipende dal controllo dei pacchetti prima dell'esecuzione, dal monitoraggio delle nuove dipendenze e dalla riduzione dell'esposizione delle credenziali a seguito della compromissione di un pacchetto.
Guarda il webinar on demand:Supply Chain Software — Gli anelli deboli sfruttati dagli hacker
Domande frequenti
Che cos'è un attacco alla catena di approvvigionamento npm?
Un attacco alla catena di approvvigionamento di npm consiste nella diffusione di codice dannoso attraverso l'ecosistema npm nel corso delle normali attività di sviluppo software. Gli autori degli attacchi riescono solitamente a raggiungere questo obiettivo compromettendo l'account di un manutentore, pubblicando un pacchetto ingannevole o inserendo comportamenti dannosi nelle dipendenze che gli sviluppatori e i sistemi CI/CD installano automaticamente.
In che modo gli hacker sono riusciti a compromettere il pacchetto npm di Axios?
Gli hacker hanno compromesso l'account npm del principale responsabile della manutenzione di Axios e hanno sfruttato i diritti di pubblicazione per rilasciare versioni dannose sia nel ramo 1.x che in quello 0.x. Gli hacker hanno inoltre modificato l'indirizzo e-mail dell'account sostituendolo con uno da loro controllato, il che ha permesso loro di mantenere il controllo del pacchetto.
Cosa ha fatto il malware nell'attacco ad Axios?
Il malware utilizzato nell'attacco ad Axios si è avvalso di un hook post-installazione per attivarsi durante l'esecuzione di npm install. L'hook ha contattato un server controllato dall'autore dell'attacco, ha scaricato un trojan di accesso remoto per macOS, Windows o Linux, lo ha avviato e ha poi tentato di cancellarne le tracce sostituendo i metadati del pacchetto con contenuti falsificati.
Perché la revisione del codice non ha individuato l'attacco alla catena di approvvigionamento di Axios?
La revisione del codice non ha individuato l'attacco a Axios perché la logica dannosa non era stata inserita nel codice sorgente di Axios. L'unica modifica visibile a livello di repository era una voce relativa alle dipendenze nel file package.json, mentre il malware vero e proprio è stato introdotto tramite un pacchetto esterno, al di fuori dell'ambito normale della revisione del codice sorgente.
In che modo le organizzazioni possono individuare i pacchetti npm dannosi prima dell'installazione?
Le organizzazioni possono individuare i pacchetti npm dannosi prima dell'installazione, analizzandone il contenuto, gli alberi delle dipendenze e gli script del ciclo di vita prima dell'esecuzione. Controlli efficaci combinano la scansione alla ricerca di malware, l'analisi delle dipendenze, l'applicazione delle politiche e l'integrazione con i processi CI/CD, in modo che i pacchetti sospetti possano essere bloccati prima che raggiungano gli ambienti di sviluppo o di compilazione.
Il "version pinning" previene gli attacchi alla catena di approvvigionamento di npm?
Il "version pinning" riduce l'esposizione alle versioni dannose appena pubblicate, poiché limita gli aggiornamenti automatici. Il "version pinning" non elimina i rischi legati alla catena di approvvigionamento, poiché una versione bloccata potrebbe essere già stata compromessa oppure potrebbero sussistere altre falle nella sicurezza. Il "version pinning" funziona al meglio se abbinato alla verifica dell'integrità, all'ispezione dei pacchetti e ai controlli in fase di esecuzione.
