Una delle fondamenta del web moderno è stata silenziosamente bucata, scatenando un allarme senza precedenti nel mondo dello sviluppo software. Axios, la celebre libreria JavaScript che macina oltre 100 milioni di download a settimana, è finita vittima di un sofisticato attacco alla supply chain su npm. Per ben tre ore, versioni malevole del pacchetto hanno infettato a cascata innumerevoli PC e server in tutto il mondo installando un pericolosissimo malware RAT. Questa diabolica minaccia, innescata dalla falsa dipendenza “plain-crypto-js”, si è adattata in automatico a Windows, Linux e macOS, spalancando le porte dei sistemi per rubare password, codici segreti aziendali e prendere il controllo delle macchine. Un incubo informatico che dimostra come nel mondo open source anche il codice più fidato possa nascondere una trappola mortale. Il caso Axios mostra quanto l’ecosistema npm resti vulnerabile anche quando viene colpita una libreria consolidata e diffusissima. Il 31 marzo 2026 due versioni compromesse del pacchetto, v1.14.1 e v0.30.4, hanno introdotto una dipendenza malevola chiamata plain-crypto-js capace di scaricare payload diversi per Linux, macOS e Windows. La finestra di esposizione è durata circa tre ore, ma l’impatto potenziale è enorme perché Axios supera i 100 milioni di download settimanali e viene integrato in applicazioni enterprise, pipeline CI/CD, strumenti interni e progetti open source. La compromissione non richiedeva alcuna interazione manuale: bastava un normale npm install o yarn install per attivare la catena di infezione. In uno scenario del genere, la fiducia nel pacchetto legittimo diventa il vero vettore offensivo.
Cosa leggere
Cisco Talos ricostruisce la catena dell’attacco contro Axios su npm
L’analisi attribuita a Cisco Talos descrive un supply chain attack estremamente rapido ma tecnicamente ben orchestrato. Gli attaccanti hanno pubblicato sul registry pubblico di npm due release compromesse di Axios, aggiungendo nel package.json la dipendenza plain-crypto-js. Questa non era una libreria innocua o di supporto, ma il vero punto di ingresso del malware. Una volta risolta dal package manager, la dipendenza eseguiva automaticamente uno script post-install capace di raccogliere informazioni sul sistema colpito e contattare un’infrastruttura remota per il download del payload successivo. L’elemento decisivo è proprio la fase automatica dell’installazione: nella maggior parte dei workflow moderni, gli sviluppatori non ispezionano manualmente tutte le dipendenze transitive, soprattutto quando il pacchetto principale è noto, affidabile e ampiamente utilizzato. Questo consente agli attaccanti di sfruttare la reputazione di Axios come scudo iniziale contro i sospetti.
La dipendenza plain-crypto-js attiva il malware dopo npm install
Il cuore tecnico dell’incidente è la dipendenza plain-crypto-js, progettata per entrare in azione immediatamente dopo l’installazione. Il codice di setup contattava un server remoto per inviare dettagli di fingerprinting sulla macchina, in particolare sistema operativo e contesto di esecuzione. In base alla risposta dell’infrastruttura C2, il pacchetto scaricava un payload personalizzato per la piattaforma. Questa logica ha due vantaggi offensivi molto chiari. Primo, riduce il rumore, perché evita di distribuire lo stesso file ovunque. Secondo, migliora la probabilità di successo, adattando il malware al sistema realmente colpito. Non si tratta quindi di un payload monolitico, ma di una catena a più stadi che usa npm solo come primo vettore. È proprio questo modello a rendere i supply chain attack più pericolosi rispetto ai malware tradizionali: il codice malevolo non arriva tramite allegato o eseguibile sospetto, ma come dipendenza apparentemente normale dentro un flusso di sviluppo standard.
I payload cambiano su Linux, macOS e Windows per massimizzare la persistenza
Secondo la ricostruzione dell’incidente, i payload consegnati variavano sensibilmente a seconda del sistema operativo. Su Linux veniva distribuito uno script Python con funzioni di backdoor, pensato per aprire canali remoti e mantenere persistenza in ambienti server o workstation di sviluppo. Su macOS il malware si presentava come un binario con naming studiato per imitare processi Apple, aumentando le probabilità di passare inosservato nei controlli superficiali. Su Windows la catena usava PowerShell per copiare un eseguibile in percorsi nascosti e avviarlo con flag che ne riducevano la visibilità all’utente. Questo approccio multipiattaforma rivela una preparazione superiore alla media: gli attaccanti non puntavano a un ambiente specifico, ma a colpire l’intera base installata di Axios, sapendo che la libreria vive sia su laptop di sviluppo sia su server di build, runner CI e ambienti applicativi. Il risultato è un RAT multipiattaforma in grado di eseguire comandi remoti, accedere al filesystem ed esfiltrare dati sensibili.
L’attacco colpisce tutta la supply chain downstream delle applicazioni JavaScript
La gravità dell’episodio non dipende solo dalla popolarità di Axios, ma dalla sua posizione all’interno della catena software. Una libreria HTTP così diffusa viene utilizzata in progetti frontend, backend Node.js, tool di automazione, applicazioni enterprise e microservizi interni. Quando una release compromessa entra nel registry, il rischio si propaga downstream a tutti gli ambienti che eseguono installazioni automatiche. Questo include workstation di sviluppatori, pipeline di build, ambienti di staging, container image e persino deploy di produzione se i lockfile vengono aggiornati o ricostruiti durante la finestra di esposizione. Anche se le versioni malevole sono rimaste online per poche ore, la persistenza di cache locali, mirror interni e artifact repository aziendali può estendere notevolmente la durata del rischio. In pratica il problema non finisce quando la release viene rimossa dal registry pubblico: continua finché tutte le copie cached e tutti i sistemi contaminati non vengono identificati e bonificati.
Il vero rischio riguarda credenziali, token e ambienti CI/CD compromessi
In un supply chain attack come quello che ha colpito Axios, il danno più serio non è soltanto l’esecuzione di codice remoto, ma l’accesso a segreti ad alto valore presenti sui sistemi di sviluppo. Un RAT installato su una macchina tecnica può intercettare token GitHub, chiavi API, credenziali cloud, accessi a database, cookie di sessione amministrativi, segreti CI/CD e certificati usati per firmare build o distribuire release. Se l’infezione raggiunge un runner di pipeline, l’attaccante può ereditare l’accesso a repository privati, registri di container, ambienti Kubernetes o infrastrutture cloud. È questo che rende particolarmente preoccupante la compromissione di una libreria JavaScript popolare: non colpisce soltanto l’utente finale, ma il cuore operativo della filiera di sviluppo. Da qui nasce la raccomandazione di trattare qualsiasi macchina che abbia installato le versioni compromesse come potenzialmente esposta a furto di credenziali, anche in assenza di segnali immediati di compromissione visibile.
Il rollback di versione è solo il primo passo della risposta all’incidente
Il ritorno alle versioni sicure v1.14.0 e v0.30.3 è la prima contromisura logica, ma non basta per chiudere davvero l’incidente. Un semplice downgrade elimina la dipendenza malevola dai nuovi deploy, ma non rimuove i payload eventualmente già eseguiti su sistemi colpiti. Per questo la risposta deve seguire una logica da incident response completa. I team devono verificare quali host abbiano installato Axios durante la finestra di compromissione, controllare la presenza di plain-crypto-js, esaminare cache npm interne, scandire i sistemi per indicatori di persistenza e rivedere i log di rete verso l’infrastruttura usata dagli attaccanti. In parallelo va eseguita la rotazione delle credenziali esposte, soprattutto su workstation di sviluppo e server CI/CD. È una misura essenziale perché, in presenza di un RAT, l’assenza di alert non equivale all’assenza di furto dati.
L’incidente Axios conferma la fragilità strutturale dell’ecosistema npm
Questo episodio riapre in modo netto il tema della sicurezza della supply chain open source. npm offre velocità, modularità e diffusione enorme, ma proprio queste qualità costituiscono anche il suo principale punto debole. Pacchetti molto popolari possono diventare vettori di attacco con impatto globale nel giro di poche ore. Il modello basato su dipendenze transitive, script post-install e aggiornamenti frequenti crea una superficie d’attacco ideale per chi vuole massimizzare il rapporto fra sforzo e diffusione. Il caso Axios dimostra inoltre che il rischio non riguarda solo pacchetti minori o maintainer sconosciuti: anche librerie mature e centrali nell’ecosistema possono diventare veicolo offensivo. Per le aziende questo significa abbandonare l’idea che la popolarità coincida automaticamente con sicurezza. Una libreria usata da milioni di progetti è più affidabile in molti casi, ma è anche un bersaglio più redditizio.
Le aziende devono passare a una difesa zero trust delle dipendenze open source
La lezione finale è chiara: ogni dipendenza, anche la più nota, deve essere trattata con un approccio zero trust. Ciò significa usare lockfile rigorosi, repository interni controllati, verifica delle release, scanning delle dipendenze prima della build, controllo degli script post-install e segmentazione degli ambienti di sviluppo rispetto ai sistemi più sensibili. Le pipeline moderne dovrebbero bloccare automaticamente pacchetti appena pubblicati finché non vengono validati o almeno sottoposti a controlli di reputazione e integrità. Allo stesso tempo gli sviluppatori devono recuperare alcune pratiche di prudenza che negli anni sono state sacrificate alla velocità: verificare changelog, monitorare variazioni improvvise nelle dipendenze, controllare gli artifact scaricati e limitare i privilegi delle workstation. Il supply chain attack che ha colpito Axios non è solo un incidente isolato, ma l’ennesimo segnale che la sicurezza del software non può più fermarsi al codice applicativo. Deve estendersi all’intera catena di distribuzione, dal registry fino all’ultimo runner di build.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
