Axios compromesso: rischio enorme per milioni di progetti open source

Una libreria JavaScript con centinaia di milioni di download settimanali può trasformarsi, nel giro di pochi minuti, in un veicolo di compromissione su larga scala. È quanto accaduto ad Axios, client HTTP tra i più utilizzati nel mondo Node.js, coinvolto il 31 marzo 2026 in un attacco alla supply chain che ha inserito codice malevolo direttamente nelle versioni ufficiali pubblicate su npm.

L’episodio si inserisce in una lunga sequenza di incidenti che hanno dimostrato come il modello di distribuzione dei pacchetti open source, nato per accelerare lo sviluppo, esponga anche a rischi sistemici: bastano credenziali sottratte o un account compromesso per propagare malware in modo silenzioso e capillare. Qualche giorno fa era toccato a LiteLLM e al progetto Trivy, entrambi prodotti cruciali in ambiente Python. Adesso è la volta di uno strumento utilizzatissimo nella sfera dello sviluppo JavaScript con npm.

Cosa sono npm e Axios

npm è il principale registry pubblico per pacchetti JavaScript e rappresenta il sistema di distribuzione standard per l’ambiente di esecuzione Node.js, ovvero la piattaforma che permette di eseguire codice JavaScript al di fuori del browser, direttamente sul server o sul sistema operativo.

Con npm gli sviluppatori possono pubblicare, versionare e installare librerie attraverso comandi come npm install, risolvendo automaticamente le dipendenze dichiarate nei file package.json.

La sua diffusione è enorme: milioni di pacchetti disponibili e un flusso continuo di aggiornamenti, spesso integrati in processi automatizzati di build e deployment.

Axios è una libreria open source utilizzata per effettuare richieste HTTP sia lato browser che lato server Node.js. Utilizza un sistema basato su promises (meccanismo asincrono che permette di gestire operazioni come le richieste HTTP in modo più ordinato), include interceptors per modificare o analizzare richieste e risposte prima che siano gestite, semplifica la gestione delle intestazioni HTTP ed esegue automaticamente il parsing delle risposte in formato JSON, convertendole in oggetti JavaScript pronti all’uso.

Grazie alla sua facilità d’impiego e alla grande compatibilità con diversi ambienti, Axios è adottato in un numero molto ampio di progetti, sia direttamente sia come dipendenza indiretta all’interno di altre librerie.

Come è avvenuta la compromissione di Axios

Gli esperti di Socket raccontano che l’attacco ad Axios ha preso forma attraverso la compromissione dell’account npm di un maintainer con privilegi elevati.

Gli aggressori hanno pubblicato due versioni apparentemente legittime, axios@1.14.1 e axios@0.30.4, senza alcuna modifica al codice sorgente visibile nel repository ufficiale. Il dettaglio più insidioso riguarda proprio la tecnica utilizzata: invece di alterare direttamente la libreria, è stata aggiunta una dipendenza esterna progettata “ad hoc”.

Nel file package.json di queste release è comparso un riferimento a plain-crypto-js@4.2.1, un pacchetto pubblicato poche ore prima e privo di collegamenti con il progetto originale. La versione precedente, 4.2.0, risultava pulita: una scelta mirata a costruire una minima credibilità nel registry prima di introdurre il payload malevolo.

Il ruolo degli script postinstall e l’esecuzione del payload

Il meccanismo di infezione sfrutta una caratteristica spesso sottovalutata di npm: gli script di installazione.

Il pacchetto malevolo include un hook postinstall che esegue automaticamente uno script Node.js al termine del comando npm install. In questo caso, il file setup.js agisce come dropper e avvia una catena di compromissione a più livelli.

Lo script contatta un server remoto e scarica componenti specifici per il sistema operativo in uso. Su macOS un binario mascherato da processo di cache di sistema, posizionato in /Library/Caches; su Windows gli aggressori ricorrono a PowerShell attraverso uno script VBScript nascosto; su Linux si utilizza uno script Python nella directory temporanea.

In tutti i casi, il comportamento converge verso l’installazione di un remote access trojan (RAT), capace di eseguire comandi arbitrari e mantenere la persistenza nel sistema compromesso.

Una finestra temporale ridotta ma ad alto impatto

Le versioni compromesse sono rimaste disponibili per un intervallo limitato, poco più di due ore, prima della rimozione dal registry.

Nonostante ciò, il rischio è concreto: qualsiasi ambiente abbia eseguito un’installazione automatica durante quella finestra – pipeline CI/CD, build server o workstation di sviluppo – potrebbe aver eseguito il codice malevolo senza alcun segnale evidente.

Axios registra oltre 100 milioni di download settimanali ed è indirettamente utilizzato da migliaia di pacchetti: un aggiornamento automatico o una build senza lockfile aggiornato basta per introdurre una dipendenza compromessa nel progetto. In molti casi non serve nemmeno importare il modulo malevolo: l’esecuzione dello script postinstall descritto al paragrafo precedente è già sufficiente.

Perché la supply chain resta il punto debole

L’episodio evidenzia un problema che nell’ultimo periodo sta diventando sempre più gravoso: la fiducia implicitamente riposta nei maintainer e nei registry pubblici.

Gli attaccanti non hanno bisogno di vulnerabilità nel codice applicativo: è sufficiente intervenire nel punto in cui il software è distribuito. Il fatto che le release malevole non avessero alcun corrispettivo su GitHub dimostra quanto sia fragile il legame tra repository e pacchetto pubblicato.

Molti processi di build (cioè le procedure automatiche che preparano e assemblano il software) si affidano ancora all’installazione dinamica di dipendenze senza effettuare controlli rigorosi sulla loro origine e integrità. La mancanza di verifiche come le firme crittografiche (meccanismi che garantiscono che il codice non sia stato alterato) o la validazione della provenienza (ossia la conferma certa della fonte del pacchetto) rende più semplice l’esecuzione di attacchi informatici, soprattutto quando gli aggressori utilizzano credenziali rubate o token di accesso npm compromessi.

Mitigazioni operative e buone pratiche

La risposta richiede interventi concreti sul ciclo di sviluppo. Il primo passo consiste nel bloccare l’uso di versioni sicure di ciascuna libreria, evitando risoluzioni automatiche verso release non verificate. Strumenti come package-lock.json o yarn.lock devono essere trattati come elementi critici di sicurezza, non semplici file di supporto.

È fondamentale disabilitare l’esecuzione automatica degli script quando possibile, ad esempio utilizzando npm install con l’opzione --ignore-scripts.

Ancora, l’analisi delle dipendenze deve diventare una pratica continua: gli scanner automatici possono aiutare ad intercettare anomalie in tempo reale.

In caso di sospetta compromissione, la bonifica del sistema non può limitarsi alla rimozione dei pacchetti. La presenza di un RAT implica la possibilità di sottrazione di un ampio ventaglio di credenziali: chiavi API, token di accesso, configurazioni “delicate” e riservate. La rigenerazione completa delle credenziali e il ripristino da ambienti puliti rappresentano l’unico approccio affidabile.

Gli attacchi alla supply chain open source non sono più eventi isolati ma operazioni mirate, rapide e altamente efficaci. L’infrastruttura di distribuzione del software, costruita per favorire la collaborazione, diventa un vettore privilegiato quando i controlli di sicurezza non tengono il passo con la complessità dei progetti.