Cosa è accaduto nell'incidente relativo alla violazione del pacchetto npm di Axios
La vicenda relativa alla violazione del pacchetto npm di Axios ci ricorda che i rischi legati al software moderno non si presentano sempre sotto forma di un tradizionale “ CVE ” o di una vulnerabilità resa nota nel codice sorgente. Talvolta il vero problema è una versione compromessa di un pacchetto, una catena di dipendenze compromessa e un percorso di esecuzione durante l’installazione che trasforma un aggiornamento di routine in un incidente di sicurezza.
Per i team addetti alla sicurezza e all’informatica, la domanda urgente non è solo: «Axios è stata colpita?» ma «Dove si trovano effettivamente le versioni interessate, quali sono state eseguite e quali devono essere ricompilate o sottoposte a verifica in questo momento?»
Secondo recenti notizie di settore riportate su , si evince da che alcuni malintenzionati hanno pubblicato versioni dannose del pacchetto Axios su npm dopo aver compromesso l'account di un responsabile della manutenzione. Secondo quanto riferito, le versioni dannose hanno interessato sia il ramo principale che quello legacy versione e hanno introdotto una dipendenza la cui funzione principale era quella di innescare l’esecuzione al momento dell’installazione.
Il punto importante di è il seguente: Axios stessa non è stata “sfruttata” nel senso classico del termine, ovvero tramite un bug software attivabile da remoto. Il rischio proveniva invece dalla catena di fornitura del software .
Perché questo episodio è importante
Axios è uno dei client HTTP JavaScript più diffusi in un ecosistema in cui sono stati individuati oltre 454.600 nuovi pacchetti dannosi nei principali registri open source nel 2025, secondo Sonatype.
Axios viene utilizzato in:
- Postazioni di lavoro per sviluppatori
- Runner CI/CD
- Server di compilazione
- Carichi di lavoro su cloud effimeri
- Sistemi di produzione che installano le dipendenze in modo dinamico
Quando un pacchetto ampiamente diffuso viene compromesso, la portata dell’impatto dipende non tanto dalla sola popolarità del pacchetto, quanto piuttosto dal numero di ambienti che hanno effettivamente risolto e installato le versioni interessate durante il periodo di esposizione.
Il numero di download settimanali ha reso Axios una delle librerie client HTTP JavaScript più utilizzate nell’ecosistema npm; ciò significa che anche un breve periodo di esposizione durante l’attacco alla catena di approvvigionamento “ marzo 2026 ” ha comportato un impatto potenziale enorme.
Versioni dannose segnalate
Sulla base delle segnalazioni pubbliche, le versioni identificate più frequentemente come dannose sono state:
| Confezione | Versione |
|---|---|
| axios | 1,14,1 |
| axios | 0,30,4 |
L'analisi pubblica ha inoltre collegato il compromesso a una dipendenza inaspettata utilizzata per innescare un comportamento successivo all'installazione.
| Dipendenza sospetta | Versione |
|---|---|
| plain-crypto-js | 4,2,1 |
Se nel Suo ambiente sono presenti tali versioni dei pacchetti o la dipendenza inaspettata sopra indicata, ciò potrebbe costituire un chiaro segnale della necessità di approfondire l'analisi.
Un’analisi indipendente di reverse engineering e delle minacce, condotta da , dimostra che i pacchetti dipendenti nell’ecosistema npm facevano affidamento su Axios al momento della compromissione della catena di approvvigionamento di marzo 2026 , evidenziando la potenziale portata dell’impatto causato dalla pubblicazione del pacchetto dannoso.
Perché la violazione del pacchetto npm di Axios è diversa da una normale vulnerabilità
La maggior parte dei programmi dedicati alle vulnerabilità è strutturata in base alle falle note, agli intervalli di versioni interessate e alle indicazioni relative alle patch. Questo evento si discosta da tale modello sotto diversi aspetti significativi.
Si trattava di un problema legato alla gestione dei pacchetti, non semplicemente di un difetto nel codice
Il rischio è derivato da un evento di pubblicazione doloso. Ciò significa che:
- Potrebbe non esserci alcun file “ CVE ” a cui fare riferimento per la risposta
- I metadati dei pacchetti sono importanti tanto quanto il codice sorgente
- Il comportamento della risoluzione delle dipendenze entra a far parte della superficie di attacco
- Gli script di installazione e gli hook post-installazione diventano prove fondamentali
Si è concentrato sul percorso delle dipendenze
Molti team continuano a concentrarsi sulle dipendenze dirette nel file ` ` e nel file `package.json`. Tuttavia, dato che molti attacchi alla catena di approvvigionamento hanno origine da dipendenze compromesse, incidenti come questo dimostrano perché le dipendenze transitive e quelle fantasma siano importanti.
Ciò rende insufficiente, di per sé, la tradizionale revisione “ App ”.
È compatibile con diversi sistemi operativi
Da ricerche pubbliche emerge che la catena di installazione abbia determinato comportamenti specifici per ciascuna piattaforma su Windows, macOS e Linux. Questo è importante perché la risposta non può limitarsi al “rischio legato al portatile dello sviluppatore” o al “rischio legato all’agente di compilazioneLinux ”. I team necessitano di una visibilità multipiattaforma.
Cosa dovrebbero fare per prima cosa i team di sicurezza
In caso di incidenti nella catena di approvvigionamento, i team spesso si lasciano andare a speculazioni prima di aver verificato la situazione reale. Prima di concentrarsi sugli indicatori, inizi con la domanda più semplice:
Le versioni dei pacchetti interessati sono disponibili da qualche parte nell’ambiente?
L'ordine in cui si svolgono le cose è importante.
Iniziate dalla presenza, passate poi al comportamento e infine valutate l’impatto
Un modello pratico di risposta potrebbe presentarsi come segue:
| Step | Question | Why it matters |
|---|---|---|
| Presenza | Disponiamo delle versioni di Axios interessate o degli artefatti delle dipendenze correlate? | Conferma se l’esposizione sia reale o ipotetica |
| Comportamento | Sono stati eseguiti script di installazione, processi figli o connessioni in uscita? | Distingue l’esposizione inattiva dall’esecuzione probabile |
| Impatto | Sono stati introdotti segreti, credenziali o punti di accesso persistenti? | Determina l'ambito del contenimento e della ricostruzione |
Questo approccio riduce il rumore e aiuta i team a evitare reazioni eccessive ai titoli dei media, pur continuando ad agire rapidamente in caso di esposizione effettiva.
A cosa prestare attenzione nel proprio ambiente
Se state valutando la potenziale esposizione derivante dalla violazione del pacchetto npm Axios, esaminate gli endpoint, i server e i sistemi CI/CD alla ricerca di una combinazione di elementi quali tracce del pacchetto, comportamento dei processi, artefatti di file e attività di rete.
Dati relativi alla confezione
Verifichi quanto segue:
- versione 1,14,1 di Axios
- versione 0,30,4 di Axios
- plain-crypto-js versione 4,2,1
- Modifiche al file di blocco che hanno comportato una risoluzione delle dipendenze inattesa
- Installazione del pacchetto durante il periodo di esposizione noto
Dati relativi agli endpoint e ai carichi di lavoro
A seconda della piattaforma, gli investigatori dovrebbero cercare indizi compatibili con l’esecuzione di script al momento dell’installazione, il download graduale di payload o processi figlio sospetti generati da Node.js o npm.
Tra le categorie utili figurano:
- Esecuzione di shell o script avviata da npm o Node.js
- Attività inattese di PowerShell, Python, curl o della shell dopo l’installazione di un pacchetto
- Il file scrive nelle directory temporanee
- File binari rinominati o camuffati
- Processi in background separati
- Traffico in uscita anomalo proveniente dai sistemi di sviluppo o di compilazione
Dati relativi al CI/CD
Le pipeline di compilazione meritano un'attenzione particolare poiché spesso presentano:
- Ampio accesso alla rete
- Segreti inseriti
- Credenziali cloud
- Token di distribuzione
- Risoluzione automatica dei pacchetti
Se un processo CI ha installato le versioni dannose del pacchetto, consideri l’evento come qualcosa di più di un semplice allarme relativo alle dipendenze di sviluppo. Recensione:
- Registri del flusso di lavoro
- Tempistica della risoluzione delle dipendenze
- Connessioni di rete in uscita
- Segreti relativi alla posizione lavorativa
- Integrità degli artefatti per le build prodotte durante il periodo di riferimento
Misure correttive immediate
Se confermate la presenza delle versioni interessate, agite con rapidità ma in modo metodico.
Le azioni riportate di seguito riflettono le misure di contenimento comunemente adottate in caso di incidenti nella catena di approvvigionamento, come la compromissione del pacchetto npm di Axios. Non sono destinate ad essere eseguite in un ordine prestabilito e le organizzazioni dovrebbero applicarle in base alla criticità del sistema, ai requisiti di approvazione e alla tolleranza al rischio.
Lista di controllo per il contenimento
| Azione | Why it matters |
|---|---|
| Fissare le versioni di Axios ritenute sicure | Impedisce che altri sistemi risolvano o installino le versioni interessate durante l’indagine |
| Rimuovere gli artefatti delle dipendenze sospetti | Garantisce che le dipendenze compromesse non vengano reintrodotte tramite installazioni memorizzate nella cache o variazioni del file di blocco |
| Si prega di verificare i sistemi che hanno eseguito il comando "npm install" durante il periodo di esposizione | Concentra l'indagine sugli endpoint, sui CI runner e sui sistemi di compilazione che con maggiore probabilità hanno eseguito script in fase di installazione |
| Aggiornare le credenziali esposte nei contesti di compilazione o di esecuzione interessati | Limita il raggio d'azione dell'attacco qualora i segreti fossero accessibili durante l'esecuzione in fase di installazione |
| Bloccare i domini o gli indirizzi IP noti come dannosi a livello di DNS e di rete | Funge da controllo compensativo nei casi in cui l’esecuzione possa aver avuto luogo, ma la ricostruzione completa sia stata posticipata |
| Ricostruire i sistemi interessati nei casi in cui sia stata confermata l'esecuzione | Ripristina la fiducia nei sistemi che potrebbero aver eseguito payload autopulenti o difficili da rilevare |
| Elementi di software di audit generati durante il periodo di esposizione | Protegge gli ambienti a valle verificando l'integrità degli artefatti prima della promozione o del rilascio |
Modifiche in materia di igiene delle confezioni sicure
Anche una volta risolto l’incidente in questione, i team dovrebbero rafforzare i controlli sui pacchi:
- Si raccomanda di specificare la versione esatta per le dipendenze critiche
- Verifica dei file di blocco durante la revisione del codice
- Limitare, ove possibile, l’uso degli script di installazione nell’ambiente CI
- Separare i segreti di compilazione dalla risoluzione di routine delle dipendenze
- Applicare controlli di provenienza per la pubblicazione e l'utilizzo dei pacchetti
- Monitorare i pacchetti presenti nei manifesti ma assenti nell'utilizzo effettivo dell'applicazione
In che modo “ Tanium ” può fornire un contributo in merito all’incidente verificatosi nella catena di approvvigionamento di Axios
Tanium The Guardian La dashboard “Supply Chain Compromise” di Axios consente ai team di sicurezza e IT di comprendere rapidamente se nel proprio ambiente siano presenti pacchetti Axios compromessi e, ove del caso, di valutare il potenziale impatto.
La dashboard si concentra innanzitutto sull’analisi dell’ambito di esposizione, consentendo ai team di monitorare le versioni compromesse di Axios (v1,14,1 e v0,30,4 legacy) utilizzando i dati di , Tanium e SBOM per determinare se i pacchetti interessati siano stati introdotti in qualche punto del proprio ambiente. Ciò consente ai team di sicurezza e IT di andare oltre le congetture e di rispondere alla domanda più urgente in caso di incidente nella catena di approvvigionamento: se il software compromesso sia effettivamente presente.
Per le organizzazioni che dispongono di funzionalità di indagine avanzate, la dashboard supporta indagini multipiattaforma Stage 2 su macOS, Windows e Linux , al fine di aiutare a identificare gli artefatti RAT e le potenziali attività di comando e controllo associate alla dipendenza dannosa.
Quando è disponibile Tanium Threat Response , i team possono inoltre intraprendere azioni di risposta quali la messa in quarantena degli endpoint interessati.
La piena funzionalità della dashboard dipende dalla presenza di una SBOM all’indirizzo Tanium e di un Threat Response all’indirizzo Tanium , con ruoli di reporting e visualizzazione adeguati, in linea con l’approccio modulare di Tanium alla convalida, all’analisi e alla risposta in materia di esposizione.
Perché i dati SBOM cambiano il modo di affrontare la questione
La distinta dei materiali software ( ) viene talvolta considerata un semplice documento di conformità, nonostante la CISA, la NSA e 19 partner internazionali abbiano dichiarato che la sua adozione costituisce una tappa fondamentale e indispensabile per la sicurezza. Episodi come questo dimostrano perché tale visione sia troppo limitata.
Quando si verifica una compromissione di un pacchetto, i dati SBOM possono aiutare a stabilire quali artefatti compilati includessero il pacchetto interessato, quali versioni fossero presenti e se fossero state dichiarate dipendenze sospette correlate. Per stabilire dove siano stati distribuiti tali artefatti o quali sistemi abbiano installato i pacchetti, sono necessari ulteriori dati di telemetria relativi a endpoint, ai container e alle pipeline.
In assenza di tale visibilità, i team tendono ad affidarsi a indicatori approssimativi:
- Ricerche nell'archivio
- Autodichiarazione degli sviluppatori
- Indizi incompleti relativi a “ EDR ”
- Verifica manuale dei file di blocco
- Ipotesi su ciò che “dovrebbe” essere installato
Si tratta di dati utili, ma non possono sostituire le prove a livello ambientale.
SBOM contro il triage basato su ipotesi
Il triage basato sull’SBOM si fonda su ciò che è effettivamente presente sugli endpoint, non su informazioni dedotte esclusivamente dai repository o dagli avvisi.
| Approach | Ciò che si impara in fretta | Limiti |
|---|---|---|
| Analisi dei rischi supportata dall’SBOM | Presenza di pacchetti/componenti in artefatti di build noti, spesso con dettagli sulla versione | Richiede comunque SBOM aggiornati e una mappatura affidabile tra gli artefatti e le risorse distribuite |
| Revisione esclusivamente su Repo | Intenzione di dipendenza dichiarata | Errori di deriva, risoluzione transitiva e realtà di esecuzione |
| IOC- solo caccia | Segnali di comportamento doloso | Potrebbe non rilevare un’esposizione inattiva o non ancora eseguita |
| Controlli manuali da parte degli sviluppatori | Contesto locale | Lento, inaffidabile e di difficile scalabilità |
L’analisi di StepSecurity dimostra che la violazione è stata determinata dall’iniezione di una dipendenza inattesa (plain-crypto-js), e non da una modifica al codice sorgente di Axios — il che evidenzia perché la visibilità a livello di componenti, come quella offerta dall’SBOM, sia fondamentale negli incidenti che coinvolgono la catena di fornitura.
Errori comuni da evitare
I team che stanno affrontando la violazione del pacchetto npm di Axios dovrebbero prestare attenzione ad alcune insidie prevedibili. Gli esempi riportati di seguito riflettono modelli comuni osservati in incidenti relativi alla catena di approvvigionamento come questo, ma le decisioni effettive in materia di risposta dovrebbero essere guidate dall’architettura, dalla tolleranza al rischio e dal contesto operativo di ciascuna organizzazione.
Considerare la questione come “una semplice questione relativa agli sviluppatori”
Qualora un pacchetto compromesso venisse eseguito nell’ambito della CI, il rischio potrebbe estendersi oltre le singole postazioni di lavoro degli sviluppatori, interessando le credenziali, gli artefatti di compilazione e gli ambienti a valle. In molte organizzazioni, i sistemi di CI dispongono di un accesso più ampio e di privilegi più elevati rispetto agli endpoint degli sviluppatori.
Si cerca esclusivamente l'utilizzo diretto di Axios
L'esposizione potrebbe non limitarsi alle applicazioni che dichiarano esplicitamente Axios come dipendenza diretta. Il pacchetto potrebbe comparire in percorsi di dipendenza transitivi, contesti di compilazione effimeri o ambienti di breve durata che è facile trascurare durante la valutazione iniziale.
Partendo dal presupposto che l’assenza di “ CVE ” indichi una bassa urgenza
Le vulnerabilità della catena di approvvigionamento possono comportare un rischio operativo concreto senza rientrare chiaramente nei flussi di lavoro tradizionali di gestione delle vulnerabilità dell’ . I team abituati a stabilire le priorità in base all’ CVE potrebbero sottovalutare gli eventi relativi all’affidabilità dei pacchetti che non corrispondono a un identificatore di vulnerabilità noto.
Pulizia in loco dopo la conferma dell'esecuzione
Qualora si confermasse la presenza di comportamenti dannosi, in particolare in ambienti con privilegi o contenenti informazioni riservate, il ripristino a partire da uno stato noto come corretto risulta spesso più sicuro rispetto al tentativo di pulizia in loco. La risposta adeguata dipenderà dal ruolo all’interno del sistema, dal livello di privilegi e dall’esposizione a credenziali sensibili.
Esempio di flusso di lavoro investigativo
La sequenza riportata di seguito illustra un possibile modo in cui i team di sicurezza e IT potrebbero strutturare un’indagine su un incidente come la compromissione del pacchetto npm di Axios. Viene fornito a titolo esemplificativo, non come lista di controllo vincolante, e dovrebbe essere adattato in base agli strumenti, al contesto e al profilo di rischio dell’organizzazione.
Fase 1: Verifica dell’esposizione
- Sistemi di gestione delle scorte con versioni di Axios interessate
- Individuare la presenza di dipendenze correlate sospette o inattese
- Map nel periodo in cui è avvenuta l'installazione del pacchetto
Fase 2: Analisi dell’esecuzione
- Analisi dei processi figli di npm e Node.js
- Verificare la creazione di file temporanei e l’avvio di sessioni della shell
- Si raccomanda di individuare eventuali interpreti di script sospetti e processi in esecuzione in modo indipendente
- Correlare le connessioni di rete in uscita dagli host interessati
Fase 3: Valutazione dell’impatto a valle
- Verifichi se le credenziali o le informazioni riservate fossero accessibili
- Esaminare le modifiche apportate agli artefatti di compilazione generati durante il periodo di esposizione
- Valutare gli indicatori di persistenza o di rilascio di un carico utile secondario
- Scegliete tra la pulizia e la ricostruzione in base al grado di sicurezza e al rischio
Fase 4: Rafforzamento
- Fissare le dipendenze a versioni di comprovata affidabilità
- Riducano, ove possibile, l’esposizione degli script di installazione
- Migliorare la copertura delle dipendenze e della SBOM
- Rafforzare la gestione delle informazioni riservate relative alla CI
- Esaminare i controlli relativi all’affidabilità degli editori e alla provenienza
Per le organizzazioni che stanno formalizzando questo tipo di risposta, pratiche più ampie di gestione delle vulnerabilità , di esposizione alle vulnerabilità e di conformità possono aiutare a coordinare l’individuazione, la definizione delle priorità e la correzione delle vulnerabilità su tutte le risorse interessate, garantendo al contempo la flessibilità necessaria in base ai rischi specifici dell’ambiente.
Domande frequenti relative all’incidente di Axios
Axios stessa era vulnerabile?
Non nel senso comune del termine, ovvero come un difetto del software con una vulnerabilità sfruttabile e una patch. Il problema consisteva in una violazione della catena di approvvigionamento causata dalla pubblicazione di pacchetti dannosi.
Quali versioni di Axios sono state segnalate come interessate dal problema?
I resoconti pubblici hanno costantemente indicato Axios 1,14,1 e 0,30,4 come le versioni npm dannose associate a questo incidente.
Perché la violazione del pacchetto npm Axios è importante, se è durata così poco?
Infatti, anche le violazioni di sicurezza di breve durata relative ai pacchetti possono comunque compromettere i sistemi di alto valore qualora, durante il periodo di esposizione, venga risolto il problema e installata la versione compromessa. La rimozione rapida non annulla le installazioni già effettuate.
Le organizzazioni dovrebbero effettuare la rotazione delle credenziali?
Qualora i pacchetti interessati fossero stati installati su sistemi con accesso a informazioni riservate, token, credenziali cloud o chiavi di distribuzione, la verifica e la rotazione delle credenziali dovrebbero rientrare nella risposta.
È sufficiente controllare i repository dei codici sorgente?
No. La revisione del repository è utile, ma non dimostra cosa sia stato effettivamente installato sugli endpoint, sugli agenti di compilazione e sui carichi di lavoro. La visibilità a livello di ambiente è fondamentale, e strumenti quali Tanium possono fornire dati di telemetria relativi a file e processi endpoint ; tuttavia, la presenza dei pacchetti deve spesso essere confermata mediante ulteriori dati relativi ad artefatti, repository e pipeline.
La lezione più importante da trarre dalla violazione del pacchetto npm di Axios
Una risposta agli incidenti ben strutturata non si basa esclusivamente sui feed relativi alle vulnerabilità. Richiede la capacità di rispondere rapidamente a tre domande concrete:
- Dove si trova effettivamente il pacchetto interessato?
- Quali problemi si sono verificati dopo l'installazione?
- Quali sono state le conseguenze operative?
Per i team di sicurezza, questa è la differenza tra reagire alle notizie dei giornali e rispondere ai fatti. Insegnamenti simili sono emersi in recenti incidenti relativi alla catena di approvvigionamento , quali XZ Utils e 3CX, , in cui l’accesso di sviluppatori di fiducia o l’infrastruttura di compilazione sono stati utilizzati in modo improprio per introdurre backdoor — rafforzando così la necessità che i team evitino di valutare il rischio software in modo troppo restrittivo, limitandosi esclusivamente a una prospettiva CVE.
Risorse aggiuntive
- Tanium Dashboard di Guardian Axios sulla violazione della catena di approvvigionamento
- Sito web di Axios
- OpenSourceMalware: database delle minacce " Community " – Analisi della violazione di Axios
- Analisi tecnica di Elastic Security
Se il Suo team sta rivalutando il modo in cui verifica l’esposizione alle dipendenze su endpoint, server e ambienti di compilazione in cui il software viene effettivamente installato ed eseguito, “ Tanium ” aiuta i team a partire dalla presenza effettiva nel mondo reale, ad analizzare il comportamento con rigore e a reagire utilizzando informazioni verificate e in tempo reale sull’ endpoint . Prenoti una demo gratuita di personalizzata in base al Suo ambiente.
