L’ecosistema JavaScript è stato scosso da un attacco alla supply chain che ha coinvolto Axios, uno dei client HTTP più utilizzati su npm, con decine di milioni di download settimanali e una presenza capillare in progetti frontend, backend e pipeline di build. L’evento, emerso tra il 30 e il 31 marzo 2026, ha mostrato ancora una volta come la fiducia implicita nei componenti open source possa trasformarsi in un vettore di compromissione su larga scala, soprattutto quando viene colpito un pacchetto estremamente diffuso e integrato in numerose dipendenze transitive.
L’attacco è stato reso possibile dal compromesso dell’account npm di uno dei maintainer principali del progetto. Con il controllo dell’account, l’attaccante ha pubblicato due versioni apparentemente legittime del pacchetto, identificate come axios@1.14.1 e axios@0.30.4. Queste release non contenevano modifiche evidenti al codice sorgente del progetto, ma introducevano una dipendenza aggiuntiva progettata esclusivamente per distribuire malware. Tale tecnica è particolarmente efficace perché evita di alterare il codice principale, riducendo la probabilità di essere individuata durante revisioni manuali o controlli superficiali.
La dipendenza inserita, denominata plain-crypto-js, rappresentava un tipico esempio di typosquatting e di abuso della risoluzione delle dipendenze. Il pacchetto non veniva mai importato nel codice Axios, ma sfruttava uno script postinstall per eseguire codice al momento dell’installazione. Questo script scaricava e installava un Remote Access Trojan multipiattaforma, progettato per funzionare su macOS, Windows e Linux. L’esecuzione avveniva automaticamente durante il comando npm install, senza richiedere alcuna interazione da parte dello sviluppatore.
La finestra temporale dell’attacco è stata relativamente breve, stimata tra circa due e tre ore prima della rimozione delle versioni compromesse dal registry npm. Tuttavia, anche una finestra così ridotta è sufficiente per provocare un impatto significativo, considerando che molte pipeline CI/CD e ambienti di build effettuano installazioni automatiche delle dipendenze. Qualsiasi progetto che abbia eseguito una nuova installazione in quel periodo avrebbe potuto scaricare il codice malevolo senza alcun segnale evidente.
Il trojan distribuito operava come un payload modulare, capace di scaricare componenti specifici per il sistema operativo. Una volta eseguito, stabiliva una comunicazione con un server di comando e controllo, da cui potevano essere inviati ulteriori istruzioni o malware secondari. Questo approccio permette all’attaccante di mantenere accesso persistente alle macchine compromesse e di espandere l’attacco a ulteriori asset, inclusi repository, credenziali cloud e sistemi interni.
L’aspetto più critico di questo incidente riguarda la natura stessa della supply chain del software moderno. Axios è una dipendenza estremamente comune, spesso inclusa indirettamente in numerosi framework e strumenti di build. Ciò significa che anche progetti che non utilizzano esplicitamente Axios potrebbero essere stati coinvolti tramite dipendenze transitive. Questo amplifica la portata dell’attacco e rende complesso determinare con precisione il numero di sistemi potenzialmente compromessi.
Alcune analisi hanno evidenziato che il malware veniva eseguito attraverso hook di installazione, una tecnica nota e già sfruttata in precedenti attacchi alla supply chain. Gli script di installazione rappresentano un punto debole intrinseco dei package manager perché consentono l’esecuzione automatica di codice con privilegi locali durante la fase di installazione. In questo caso, l’attaccante ha sfruttato proprio questo meccanismo per distribuire il RAT in modo invisibile e scalabile.
Ulteriori elementi emersi dalle analisi indicano che le versioni malevole non erano associate a commit ufficiali nel repository GitHub del progetto. Ciò suggerisce che la pubblicazione è avvenuta direttamente tramite il token npm compromesso, bypassando la pipeline CI/CD standard utilizzata dal progetto per le release legittime. Questo dettaglio è importante perché evidenzia una debolezza strutturale: anche con workflow sicuri, la compromissione dell’account del maintainer può consentire la pubblicazione diretta di pacchetti non verificati.
Questo attacco dimostra come la fiducia nella catena delle dipendenze possa essere sfruttata per ottenere accesso a un numero elevato di ambienti di sviluppo. Un singolo pacchetto compromesso può propagarsi rapidamente attraverso build automatizzate, container, sistemi CI e ambienti di produzione. L’impatto potenziale include il furto di credenziali, l’accesso ai repository privati e l’infiltrazione nelle infrastrutture cloud.
Alcune analisi di threat intelligence hanno anche suggerito possibili collegamenti con gruppi avanzati, evidenziando come operazioni di questo tipo siano sempre più sofisticate e mirate a obiettivi strategici, come aziende fintech e progetti legati a criptovalute. Questo conferma l’evoluzione degli attacchi supply chain da opportunistici a mirati e con finalità economiche o geopolitiche.
L’episodio Axios evidenzia quindi una criticità strutturale del modello open source moderno: la dipendenza da pochi maintainer e la distribuzione automatica delle release tramite registri pubblici. Quando uno di questi punti viene compromesso, l’effetto a catena può coinvolgere un intero ecosistema software. Il fatto che il codice malevolo sia stato introdotto tramite una dipendenza nascosta e non direttamente nel codice principale dimostra inoltre che i controlli tradizionali, basati sull’ispezione del codice sorgente, non sono più sufficienti.