Questa notizia riguarda una fetta precisa di lettori: chi ha un’agenzia web, una software house o lavora come sviluppatore in proprio. Se non è il tuo caso, la storia resta istruttiva per un motivo solo — la vittima dell’attacco è un’azienda che vende sicurezza informatica.
L’11 luglio qualcuno è entrato in possesso delle credenziali con cui Jscrambler pubblica il proprio pacchetto su npm, l’archivio da cui il mondo dello sviluppo JavaScript scarica i componenti già pronti. Con quelle credenziali ha pubblicato versioni del pacchetto modificate, con dentro un programma per rubare dati.
Cosa è successo, in parole semplici
Chi costruisce software non riscrive tutto da zero: assembla pacchetti scritti da altri, scaricandoli automaticamente con un comando (npm install). È efficiente, ed è anche il punto debole: se qualcuno riesce a sostituire uno di quei pacchetti con una versione avvelenata, il codice malevolo entra da solo in ogni computer e in ogni server che lo installa. Nessuno deve cliccare su niente.
È esattamente ciò che è accaduto. Il programma nascosto nel pacchetto è un infostealer scritto in Rust, funzionante su Linux, Windows e macOS. Non cerca file personali: cerca le chiavi di casa.
- codice sorgente e file dei progetti;
- credenziali degli sviluppatori: Git, SSH, variabili d’ambiente, token CI/CD (quelli che mandano il software in produzione automaticamente);
- credenziali cloud: AWS, Azure, GCP, Kubernetes;
- configurazioni degli strumenti di intelligenza artificiale usati per programmare (Claude, Cursor, VS Code);
- wallet di criptovalute e relative seed phrase;
- dati dei browser e delle app di collaborazione come Slack e Discord.
Tanti ne sono bastati nella finestra prima della rimozione. Ogni download su una macchina di sviluppo o su un server di build è un potenziale furto di token cloud e chiavi di deploy.
Fonte: Socket, BleepingComputer — luglio 2026
Il dettaglio che le prime cronache si sono perse
Qui serve precisione, perché le fonti non concordano e la differenza è operativa.
Diverse testate elencano come compromesse le versioni 8.14, 8.16, 8.17 e 8.20. L’analisi di Socket, che ha rilevato il pacchetto malevolo sei minuti dopo la pubblicazione, ne aggiunge una: anche la 8.18.0 lo è. E soprattutto documenta un cambio di tecnica che conta.
Nelle prime versioni il codice malevolo partiva durante l’installazione, agganciato a un meccanismo automatico (l’install hook). Contro questo tipo di attacco esiste una contromisura nota fra gli addetti: installare con l’opzione --ignore-scripts, che disattiva quegli automatismi. Dalla 8.18.0 quel riparo non funziona più. Gli attaccanti hanno tolto l’aggancio all’installazione e hanno spostato lo stesso identico codice dentro il pacchetto vero e proprio, in modo che parta quando il pacchetto viene usato o quando se ne lancia il comando da terminale. Socket lo definisce un’evasione deliberata: aggira gli scanner che controllano solo gli script di installazione e sopravvive a npm install --ignore-scripts.
Compromesse: 8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0. Pulite: 8.15.0 (release interim) e 8.22.0, la versione sicura a cui aggiornare o su cui fissare il pin. Attenzione: la 8.18.0 manca in diverse liste circolate nelle prime ore.
Perché aggiornare, da solo, non chiude l’incidente
È il punto che un titolare deve avere chiaro, ed è controintuitivo.
Il riflesso naturale è «aggiorniamo all’ultima versione e siamo a posto». Aggiornare serve — ferma l’emorragia — ma non annulla ciò che è già uscito. Se il pacchetto avvelenato è passato in una build tra l’11 e il 13 luglio, i token cloud, le chiavi di deploy e le credenziali Git di quella macchina sono già nelle mani di qualcun altro, e continuano a funzionare finché non vengono cambiati. Un attaccante con un token CI/CD valido non ha bisogno di rientrare dalla porta: ha le chiavi per pubblicare codice a nome tuo, anche fra un mese.
Tradotto per chi guida l’azienda: la domanda da fare al team non è «avete aggiornato?», ma «abbiamo ruotato le credenziali?».
Cosa fare, in concreto
- Verifica se il pacchetto è passato di lì. Chiedi al team di controllare i log di build e i file di lock dei progetti nella finestra 11-13 luglio, cercando le versioni 8.14.0, 8.16.0, 8.17.0, 8.18.0 e 8.20.0.
- Aggiorna alla 8.22.0 (o fissa il pin su quella versione).
- Ruota i segreti, in ordine di danno potenziale: prima i token CI/CD e le credenziali cloud (AWS, Azure, GCP, Kubernetes), poi le chiavi SSH e i token Git, poi le altre credenziali presenti in quelle macchine. Non è un adempimento formale: è l’unica azione che invalida ciò che è stato rubato.
- Se non hai un team interno, gira questa richiesta al fornitore che ti gestisce lo sviluppo e chiedi una risposta scritta su due punti: se le versioni colpite sono state usate, e quando sono state ruotate le credenziali.
In breve
Le credenziali di pubblicazione di Jscrambler sono state violate l’11 luglio e cinque versioni del pacchetto npm — 8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0 — hanno distribuito un infostealer che punta a token cloud, chiavi di deploy e credenziali Git. La versione pulita è la 8.22.0. Dalla 8.18.0 la protezione --ignore-scripts non basta più. E aggiornare senza ruotare i segreti lascia la porta aperta.