Gli aggressori hanno rubato un token di accesso npm di lunga durata appartenente al fornitore principale. assila libreria client HTTP più popolare in JavaScript. Le versioni dannose prendono di mira macOS, Windows e Linux. Sono rimasti attivi nel registro npm per circa tre ore prima di essere rimossi.

Axios ottiene più di 100 milioni di download a settimana. Lo riferisce Wiz Esiste in quasi l’80% degli ambienti cloud e di codice e tocca qualsiasi cosa, dai frontend React alle pipeline CI/CD e alle funzioni serverless. Cacciatore rilevato Le prime infezioni si sono verificate 89 secondi dopo la messa in rete del pacchetto dannoso, confermando che almeno 135 sistemi tra i clienti erano stati compromessi durante il periodo di esposizione.

Questo è il terzo importante npm La riconciliazione della catena di fornitura sarà raggiunta entro sette mesi. Ciascuno ha beneficiato delle credenziali del manutentore. Questa volta l’obiettivo aveva adottato tutte le difese suggerite dalla comunità della sicurezza.

Una credenziale, due specializzazioni, 39 minuti

L’aggressore ha preso il controllo npm L’account di @jasonsaayman, un dirigente di spicco di Axios, ha sostituito l’e-mail dell’account con un indirizzo ProtonMail anonimo e lo ha pubblicato tramite pacchetti velenosi. npml’interfaccia della riga di comando di. Ciò ha completamente bypassato la pipeline CI/CD di GitHub Actions del progetto.

L’aggressore non ha mai toccato il codice sorgente di Axios. Invece entrambi i rami di rilascio hanno ricevuto un’unica nuova dipendenza: plain-crypto-js@4.2.1. Nessuna parte della codebase lo importa. Il pacchetto esiste solo per eseguire uno script post-installazione che rilascia un RAT multipiattaforma sul computer dello sviluppatore.

La messa in scena era precisa. 18 ore prima della pubblicazione di Axios, l’aggressore ha pubblicato una versione pulita su Axios. plain-crypto-js sotto una voce separata npm Account per creare la cronologia delle pubblicazioni ed evitare avvisi del browser per nuovi pacchetti. Poi è arrivato il 4.2.1 armato. Entrambi i rami di rilascio hanno raggiunto entro 39 minuti. Sono stati precostruiti tre payload specifici della piattaforma. Una volta eseguito, il malware si cancella e sostituisce un file package.json pulito per evitare analisi forensi.

Passo Sicurezzadefinire il compromesso, PRESAlo ha descritto come uno degli attacchi alla catena di fornitura più complessi dal punto di vista operativo mai documentati contro i primi 10 npm pacchetto.

Difesa che esiste sulla carta

Axios ha fatto le cose giuste. Le versioni 1.x legittime vengono inviate tramite GitHub Actions. npmMeccanismo di editore affidabile OIDC che collega crittograficamente ogni versione a un flusso di lavoro CI/CD verificato. Il progetto ha ottenuto le approvazioni delle risorse SLSA. Secondo ogni misura moderna, lo stack di sicurezza sembrava solido.

Niente di tutto ciò aveva importanza. Huntress ha esaminato il flusso di lavoro della pubblicazione e ho trovato il divario. Il progetto è comunque passato NPM_TOKEN Come variabile di ambiente proprio accanto alle credenziali OIDC. Quando entrambi sono presenti, npm utilizza il token per impostazione predefinita. Il token classico di lunga durata era il metodo di autenticazione effettivo per ogni problema, indipendentemente da come era configurato l’OIDC. L’aggressore non ha mai dovuto sconfiggere l’OIDC. Ci hanno fatto il giro. Un vecchio token era lì come percorso di autenticazione parallelo e npmLa sua stessa gerarchia preferiva tranquillamente questo.

“Nella mia esperienza in AWS, è molto comune che i meccanismi di autenticazione legacy persistano”, ha affermato Merritt Baer, ​​CSO di Enkrypt AI ed ex vice CISO di AWS, in un’intervista esclusiva con VentureBeat. “Entrano in gioco i controlli moderni, ma a meno che i vecchi token o chiavi non siano deprecati, il sistema li preferisce silenziosamente. Proprio come abbiamo visto con SolarWinds, gli script legacy hanno semplicemente bypassato il tracciamento.”

addetto alla manutenzione Rilasciato su GitHub dopo aver scoperto il compromesso: “Sto cercando di ottenere supporto per capire come ciò accade. Ho 2FA/MFA su quasi tutto ciò con cui interagisco.”

Documentato da Endor Labs differenza giudiziaria. Legittimo axios@1.14.0 Puntava alla fonte OIDC, a un record di editore affidabile e a un collegamento gitHead a un commit specifico. Dannoso axios@1.14.1 Non ce n’era. Qualsiasi strumento che controllasse la fonte segnalerebbe immediatamente il divario. Tuttavia, la verifica della fonte è facoltativa. Nessuna porta di registrazione ha rifiutato il pacchetto.

Tre attacchi, sette mesi, stessa causa

Volare npm La catena di approvvigionamento sarà compromessa entro sette mesi. Ognuno ha iniziato con una credenziale di manutentore rubata.

Verme Shai-Hulud È stato girato nel settembre 2025. Un unico account di manutenzione phishing ha fornito agli aggressori una base autoreplicante. Più di 500 pacchiraccolto npm token, credenziali cloud e segreti GitHub vengono rivelati man mano che si diffondono. La CISA ha emesso una raccomandazione. GitHub revisionato npm’l’intero modello di autenticazione in risposta.

Successivamente, nel gennaio 2026, Koi Security Ricerca PackageGate Abbiamo eliminato sei vulnerabilità zero-day in NPM, pnpm, vlte Bun, che penetra le difese adottate dall’ecosistema dopo Shai-Hulud. Il blocco dell’integrità del file e il blocco degli script non sono riusciti entrambi in determinate condizioni. Tre gestori di pacchetti su quattro hanno applicato la patch in poche settimane. npm ha chiuso il rapporto.

Ora l’assioma. Un token di lunga durata rubato ha emesso un RAT attraverso entrambi i rami di rilascio nonostante tutte le misure di rafforzamento implementate post-OIDC, SLSA e Shai-Hulud.

npm Ha effettuato vere riforme dopo Shai-Hulud. La creazione di nuovi token classici è ora deprecata, ma i token preesistenti sono sopravvissuti fino alla data di revoca definitiva. FIDO 2FA è diventato obbligatorio, l’emissione di token di accesso dettagliato è stata limitata a sette giorni e l’emissione attendibile tramite OIDC ha fornito ai progetti un’alternativa crittografica alle credenziali archiviate. Nel loro insieme, questi cambiamenti hanno consolidato tutto nella parte inferiore dell’account del manutentore. Ciò che non hanno cambiato è stato l’account stesso. Le credenziali sono rimaste l’unico punto di fallimento.

“Il compromesso d’identità è un tema ricorrente in tutto il mondo. npm violazioni”, ha detto Baer. “Questo non è solo un problema di password deboli. È strutturale. Senza credenziali temporanee, MFA forzata o ambienti di compilazione e firma isolati, l’accesso del manutentore rimane l’anello debole”.

Quale npm invia e questo attacco va oltre

Di cosa hanno bisogno i leader SOC

npm difesa inviata

contro l’attacco di Axios

spazio

Impedisci l’emissione di token rubati

È richiesto FIDO 2FA. Token granulari, data di scadenza a 7 giorni. I token classici vengono ritirati

Bypassato. Il token legacy esisteva insieme a OIDC. npm preferiva il gettone

Nessuna applicazione rimuoverà i vecchi token quando è configurato OIDC

Verifica l’origine del pacchetto

Rilascio attendibile OIDC tramite azioni GitHub. Approvazioni SLSA

Bypassato. Le versioni dannose non avevano alcuna fonte. Rilasciato tramite CLI

Nessuna porta rifiuta i pacchetti con risorse mancanti da progetti precedentemente posseduti

Cattura il malware prima che si installi

Scansione automatica Socket, Snyk, Aikido

Parziale. La presa è stata contrassegnata in 6 minuti. Primi contagi riscontrati in 89 secondi

Divario tra rilevamento e rimozione. I browser lo rilevano e la rimozione del registro richiede ore

Blocca l’esecuzione post-installazione

–ignore-script consigliati in CI/CD

Non obbligatorio. npm Viene eseguito dopo l’installazione per impostazione predefinita. pnpm blocchi per impostazione predefinita; npm non

postinstall rimane il principale vettore di malware in tutti i principali software npm Attacco dal 2024

Blocca le versioni delle dipendenze

Implementazione del file di blocco npm ci

È efficace solo se il file di blocco viene elaborato prima della compromissione. Intervalli fissi risolti automaticamente

Intervalli di correzione npm predefinito. La maggior parte dei progetti si risolve automaticamente nell’ultimo minore

Cosa fare adesso nella tua attività

I leader del SOC le cui organizzazioni eseguono Node.js dovrebbero considerare questo come un incidente attivo finché non confermano che i sistemi sono puliti. La finestra di esposizione di tre ore cadeva durante le ore di picco dello sviluppo nei fusi orari dell’Asia-Pacifico e qualsiasi pipeline CI/CD che eseguiva npm install durante la notte poteva rimuovere automaticamente la versione compromessa.

“La prima priorità è la valutazione dell’impatto: quali costruttori e consumatori a valle hanno utilizzato il pacchetto compromesso?” Ha detto Baer. “Poi contenimento, patch e infine reporting trasparente alla leadership. Cosa è successo, cosa è stato esposto e quali controlli impediranno che si ripeta. Le lezioni apprese da log4j e dallo streaming di eventi mostrano che velocità e chiarezza sono importanti quanto la riparazione stessa.”

  • Controlla l’esposizione. Cerca file di blocco e log CI axios@1.14.1, axios@0.30.4O plain-crypto-js. Aggiungi a: axios@1.14.0 O axios@0.30.3.

  • Se colpito, presuppone la riconciliazione. Ricostruire le macchine interessate riportandole ad uno stato sicuramente funzionante. Restituisce tutte le credenziali accessibili: token npm, chiavi AWS, chiavi SSH, credenziali cloud, segreti CI/CD, valori .env.

  • Blocco C2. Per aggiungere sfrclak.com e 142.11.206.73 Agli elenchi di blocchi DNS e alle regole del firewall.

  • Controllare le strutture del RAT. /Library/Caches/com.apple.act.mond su macOS. %PROGRAMDATA%\wt.exe su Windows. /tmp/ld.py on Linux. Se trovato, eseguire una ricostruzione completa.

  • Harden va avanti. Rendilo obbligatorio npm ci --ignore-scripts Nel CI/CD. Applica il blocco solo ai caricamenti dei file. Rifiuta i pacchetti a cui manca l’origine dei progetti posseduti in precedenza. Controlla se i token legacy coesistono con OIDC nei tuoi flussi di lavoro di pubblicazione.

Gap identitario che nessuno colma

Tre attacchi in sette mesi. Ognuno è diverso in termini di applicazione ma uguale in termini di causa principale. npmIl modello di sicurezza di considera ancora gli account dei singoli manutentori come la principale fonte di fiducia. Questi account rimangono vulnerabili alla compromissione delle credenziali, indipendentemente dal numero di livelli aggiunti verso il basso.

“L’intelligenza artificiale rileva i pacchetti rischiosi, verifica l’autenticazione legacy e accelera la risposta del SOC”, ha affermato Baer. “Ma le persone stanno ancora controllando le credenziali del proprio fornitore di servizi sanitari. Stiamo riducendo il rischio. Non lo stiamo eliminando.”

La verifica obbligatoria dell’origine, con la pubblicazione manuale della CLI completamente disabilitata, avrebbe rilevato questo attacco prima che raggiungesse il registro. Lo stesso vale per la firma multilaterale obbligatoria, in cui nessun singolo manutentore può rilasciare una versione per conto proprio. Nessuno dei due è implementato oggi. npm segnalato che la disabilitazione dei token per impostazione predefinita quando è abilitata la pubblicazione attendibile è sulla tabella di marcia. Fino alla spedizione, ogni progetto che esegue OIDC con un token legacy presenta lo stesso punto cieco di Axioms.

L’amministratore di Axios ha fatto ciò che voleva la comunità. Un vecchio token di cui nessuno si accorgeva era ancora attivo e li minava tutti.

Collegamento alla fonte

RELATED ARTICLESMORE FROM AUTHOR