Il caso Axios riporta al centro un rischio noto ma spesso sottovalutato: la compromissione della software supply chain attraverso pacchetti open source usati ogni giorno da sviluppatori, aziende e pipeline CI/CD. Tra il 30 e il 31 marzo 2026, due release malevole del popolare client HTTP per JavaScript sono finite su npm dopo il furto delle credenziali di un maintainer. Secondo CrowdStrike, dietro l’operazione ci sarebbe con confidenza moderata STARDUST CHOLLIMA, attore con nexus nordcoreano che in passato ha privilegiato obiettivi economici e operazioni legate alla generazione di liquidità.
Le versioni compromesse e la finestra di esposizione
Nel post-mortem ufficiale pubblicato dal team di Axios, le versioni compromesse sono axios@1.14.1 e axios@0.30.4. Entrambe hanno introdotto una dipendenza aggiuntiva, plain-crypto-js@4.2.1, capace di installare un remote access trojan su macOS, Windows e Linux. Le release malevole sono rimaste online per circa tre ore prima della rimozione, con una finestra che il maintainer colloca tra le 00:21 UTC e le 03:15 UTC del 31 marzo 2026.
Il dettaglio tecnico più rilevante è che il codice di Axios quasi non cambia affatto. StepSecurity segnala che, nel confronto tra 1.14.0 e 1.14.1, la differenza sostanziale riguarda il solo package.json, modificato per inserire la dipendenza malevola. È un pattern tipico degli attacchi più insidiosi: il progetto principale resta apparentemente intatto, mentre il payload entra nella catena di installazione tramite un componente secondario e un hook di postinstall.
Il malware usato nel caso Axios
Secondo CrowdStrike, il malware distribuito in questa operazione è una variante aggiornata di ZshBucket. La novità non riguarda solo la compatibilità multipiattaforma. La nuova versione adotta un protocollo JSON comune per gli impianti destinati a Linux, macOS e Windows e introduce comandi che permettono all’operatore di iniettare payload binari, eseguire script o comandi arbitrari, enumerare il file system e perfino terminare da remoto l’impianto. Per CrowdStrike si tratta di un salto tecnico rispetto alle varianti precedenti, che avevano capacità più semplici di download ed esecuzione.
StepSecurity aggiunge un altro elemento importante: il dropper contattava il dominio sfrclak[.]com per recuperare i payload di secondo stadio e, dopo l’esecuzione, cercava di ridurre le tracce sostituendo il proprio package.json con una versione pulita. In altre parole, non si tratta di un test o di un semplice infostealer rudimentale, ma di un impianto pensato per dare accesso remoto e per ostacolare l’analisi successiva.
Perché CrowdStrike parla di STARDUST CHOLLIMA
L’attribuzione non è formulata in termini assoluti. CrowdStrike parla di confidenza moderata e basa la valutazione su due fattori: l’uso di una variante aggiornata di ZshBucket, malware che la società considera peculiare di STARDUST CHOLLIMA, e alcune sovrapposizioni infrastrutturali. Il dominio sfrclak[.]com, usato come C2, risulta associato all’IP 142.11.206[.]73 e condivide un host services banner hash con altri due indirizzi. Uno di questi, 23.254.203[.]244, era già stato collegato a STARDUST CHOLLIMA a dicembre 2025; un altro, 23.254.167.216, era invece comparso in attività attribuite a FAMOUS CHOLLIMA nel maggio 2025. Proprio questa sovrapposizione impedisce a CrowdStrike di alzare il livello di confidenza.
Il profilo storico del gruppo rafforza però la pista. In un proprio actor profile, CrowdStrike descrive STARDUST CHOLLIMA come un attore legato alla DPRK che ha preso di mira istituzioni finanziarie e infrastrutture utili alla generazione di fondi. Anche nel caso Axios, CrowdStrike ritiene probabile una motivazione economica, coerente con le campagne che hanno colpito in passato il settore crypto, il mondo fintech e repository npm o PyPI.
Un attacco che pesa per tutto l’ecosistema JavaScript
L’impatto potenziale dipende dal ruolo di Axios nell’ecosistema. StepSecurity lo definisce il client HTTP più usato in ambito JavaScript e parla di oltre 100 milioni di download settimanali, oltre a milioni di repository e centinaia di migliaia di pacchetti dipendenti. La rilevanza del caso non deriva quindi solo dalla sofisticazione tecnica, ma anche dal fatto che un singolo maintainer compromesso può trasformare una libreria comune in un vettore verso developer workstation, runner CI/CD e ambienti di build aziendali.
C’è poi un dettaglio che aiuta a capire il livello operativo dell’attaccante. Nel post-mortem di Axios si legge che i primi issue pubblici aperti dalla community furono cancellati tramite l’account compromesso. StepSecurity afferma che questa sequenza si sarebbe ripetuta più volte, circa venti, nel tentativo di rallentare l’allerta pubblica. È un comportamento che suggerisce disciplina operativa e attenzione alla gestione del tempo, due elementi che fanno la differenza quando un pacchetto resta online anche solo poche ore.
Cosa cambia per maintainer, aziende e team DevSecOps
Il caso arriva mentre GitHub e npm avevano già avviato un rafforzamento delle difese della registry. Tra settembre e ottobre 2025 GitHub ha annunciato token granulari con durata più breve, una stretta sull’autenticazione e una maggiore spinta verso il trusted publishing. La documentazione npm indica inoltre che l’impostazione raccomandata per i pacchetti è quella che impone la 2FA e vieta l’uso di token per la pubblicazione, proprio per ridurre il rischio di abusi in caso di furto credenziali.
Per chi teme un’esposizione concreta, il post-mortem di Axios è molto netto: se nel lockfile compaiono axios@1.14.1, axios@0.30.4 o plain-crypto-js, la macchina va trattata come compromessa. Le indicazioni ufficiali parlano di downgrade a 1.14.0 o 0.30.3, rimozione della dipendenza malevola, rotazione di segreti e credenziali e verifica di eventuali connessioni verso sfrclak[.]com o 142.11.206.73 sulla porta 8000. Nel frattempo, la pagina npm di Axios mostra come versione più recente la 1.15.0, pubblicata una settimana prima dell’8 aprile 2026.
Perché questo episodio merita attenzione
L’attacco ad Axios non è soltanto un incidente di repository. È il segnale di una fase in cui i gruppi più attrezzati cercano accesso a monte, dentro gli strumenti che gli sviluppatori usano ogni giorno, invece di puntare solo al bersaglio finale. Se l’attribuzione di CrowdStrike reggerà anche dopo ulteriori analisi, il caso mostrerà ancora una volta come le operazioni con finalità economiche, soprattutto nell’orbita nordcoreana, sappiano unire social engineering, supply chain compromise e malware cross-platform dentro una stessa catena di attacco.
Fonti principali: analisi di CrowdStrike, post-mortem ufficiale del repository Axios, analisi tecniche di StepSecurity, documentazione npm e aggiornamenti ufficiali GitHub sulla sicurezza della supply chain.










Scrivi una risposta