Attori minacciosi hanno compromesso le credenziali npm di Jscrambler e pubblicato cinque versioni malevole del pacchetto jscrambler tra le 15:12 e le 17:53 UTC dell'11 luglio 2026. Il payload, un infostealer Rust cross-platform nascosto in un container binario con estensione .js, raccoglie credenziali da ambienti di sviluppo, cloud, tool AI e wallet crittografici. L'attacco presenta una doppia generazione tecnica: la prima sfrutta i preinstall hook, la seconda — pubblicata tre giorni dopo il rilascio di npm 12 che disabilita gli install script — si attiva tramite require(), aggirando la nuova mitigazione.
- Cinque versioni malevole (8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0) pubblicate in circa tre ore, con la 8.15.0 pulita interposta — pattern che suggerisce controllo manuale del flusso.
- Il payload è un binario nativo Rust (ELF, PE32+, Mach-O) da 7,8 MB, non JavaScript, mascherato da file .js tramite header magico custom di 5 byte.
- La generazione 2 (8.18.0, 8.20.0) bypassa
npm install --ignore-scriptsiniettando il dropper indist/index.jsattivato al primorequire(). - Capacità eBPF su Linux per hook kernel-level senza touch filesystem; persistenza via scheduled task su Windows e LaunchAgent su macOS.
Come è avvenuta la compromissione
La causa radice è confermata: credenziali npm di publishing compromesse, poi revocate da Jscrambler. Secondo la dichiarazione dell'azienda riportata da BleepingComputer, l'incidente è "limitato a quel pacchetto" e non ha coinvolto altri prodotti, incluso Webpage Integrity. Le versioni malevole non hanno alcuna corrispondenza nel repository GitHub pubblico: nessun commit, tag o pull request documenta il loro rilascio. Socket ha rilevato la versione 8.14.0 sei minuti dopo la pubblicazione; StepSecurity OSS AI Package Analyst ha assegnato il massimo suspicion score (0) già al momento del publish.
I timestamp esatti ricostruiti da StepSecurity mostrano una sequenza serrata: 8.14.0 alle 15:12, 8.16.0 alle 17:26, 8.17.0 alle 17:41, 8.18.0 alle 17:46, 8.20.0 alle 17:53 UTC. L'intervallo di circa tre ore e la presenza della 8.15.0 pulita tra la 8.14.0 e la 8.16.0 indicano un operatore che controlla attivamente il processo, non un sistema automatico a rilascio continuo. Jscrambler ha elencato quattro versioni nel proprio advisory, omettendo la 8.18.0 — un dettaglio non chiarito.
"Il payload non è JavaScript incorporato. È un binario nativo compilato in Rust... contrabbandato dentro un file con estensione .js dietro un header magico custom di 5 byte." — StepSecurity
L'architettura del payload: un container binario multi-piattaforma
Il file dist/intro.js nelle versioni malevole pesa 7,8 MB contro i 37,8 kB della versione pulita. Dietro l'estensione .js si nasconde un container gzip con tre binari nativi: ELF x86-64 per Linux, PE32+ per Windows, Mach-O arm64 per macOS. Il magic header 1B 43 53 49 01 — identico byte-per-byte in tutte e cinque le versioni — permette al dropper setup.js di identificare e decomprimere il payload corretto per l'host target.
Una volta estratto, il binario viene scritto in una directory temporanea con nome random e eseguito in modalità detached. I tre hash SHA-256 documentati da The Hacker News e StepSecurity sono: Linux fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd; Windows b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903; macOS c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd.
La doppia generazione: da preinstall a require()
Le prime tre versioni (8.14.0-8.17.0) rappresentano la generazione 1: l'attivazione avviene tramite il campo preinstall in package.json, eseguito automaticamente durante npm install. Questa è la tecnica classica di supply chain npm, ora mitigata da npm 12 rilasciato l'8 luglio 2026 con install script disabilitati di default.
La generazione 2 (8.18.0-8.20.0) risponde a questa hardening. Il dropper è inlinizzato direttamente in dist/index.js, il punto di ingresso principale del pacchetto, e si attiva al primo require("jscrambler") — operazione che avviene necessariamente quando il modulo viene importato nell'applicazione target. Come notano The Hacker News e StepSecurity, npm install --ignore-scripts non arresta questa variante: il codice malevolo è già nel file principale del modulo.
L'intervallo di tre giorni tra npm 12 e l'attacco non è casuale. L'operatore ha osservato il cambiamento di default, ha verificato che i client legacy restassero vulnerabili ai preinstall hook, e ha preparato contemporaneamente una variante resistente alla nuova configurazione. La velocità di adattamento è un indicatore di maturità operativa.
Cosa ruba e come persiste
L'infostealer bersaglia credenziali da multiple superfici di attacco. I target documentati da BleepingComputer, The Hacker News e Security Boulevard includono: ambienti di sviluppo (Git, SSH, variabili d'ambiente, token CI/CD); piattaforme cloud (AWS, Azure, GCP, Kubernetes); tool AI (Claude, Cursor, Windsurf, VS Code, Zed) con configurazioni MCP (Model Context Protocol); wallet crittografici (MetaMask, Phantom, Coinbase, Exodus, Trust); messaging aziendale (Slack, Discord, Telegram); e il password manager Bitwarden.
La capacità eBPF su Linux, rilevata da StepSecurity tramite analisi della import table, è particolarmente significativa. Il payload linka libbpf.so.1 e utilizza bpf_object__open_mem, bpf_object__load e bpf_program__attach per caricare programmi eBPF direttamente dalla memoria, senza scrivere sul filesystem. Questo consente hook a livello kernel con minima traccia forense. Su Windows la persistenza avviene tramite scheduled task nascosto con rilancio ogni minuto; su macOS tramite LaunchAgent in ~/Library/LaunchAgents. Entrambe le piattaforme implementano anti-debug: IsDebuggerPresent su Windows, sysctl/sysctlbyname con P_TRACED su macOS.
Gli indicatori di rete osservati da StepSecurity con Harden-Runner includono chiamate outbound verso archive.torproject.org e check.torproject.org, oltre agli IP 37.27.122.124 e 57.128.246.79. L'esfiltrazione avviene via TLS attraverso la rete Tor.
Cosa fare adesso
StepSecurity ha emesso l'indicazione operativa più netta: "Se hai installato una qualsiasi delle versioni jscrambler 8.14.0, 8.16.0, 8.17.0, 8.18.0 o 8.20.0: tratta l'host come compromesso." Questa raccomandazione si traduce in quattro priorità.
Prima: verificare i lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) alla ricerca delle cinque versioni malevole. La versione 8.15.0 risulta pulita, la 8.22.0 è quella raccomandata come pulita dalle fonti.
Seconda: nei sistemi dove è stata eseguita una delle versioni compromesse, effettuare rotazione completa di tutte le credenziali presenti nelle categorie target elencate dalla fonte — non solo npm, ma anche Git, cloud, CI/CD, tool AI e wallet crittografici.
Terza: controllare la presenza di persistenza OS-level: scheduled task su Windows con esecuzione minutaria non documentata, e LaunchAgent in ~/Library/LaunchAgents su macOS. L'analisi della rete outbound verso i domini Tor e gli IP indicati può confermare compromissione attiva.
Quarta: verificare che le pipeline CI/CD non riutilizzino cache o artefatti derivati da build con le versioni malevole. Il payload si attiva su require(): un'immagine container costruita con il pacchetto compromesso rimane infetta anche se il lockfile è stato successivamente corretto.
Il paradosso di un vendor di "code integrity"
Jscrambler vende prodotti di protezione client-side e integrità del codice. Il fatto che il proprio pacchetto npm sia diventato vettore di una delle supply chain attack più sofisticate del 2026 — con adattamento attivo a mitigazioni appena rilasciate — solleva questioni sul modello di trust che le toolchain di sicurezza richiedono agli sviluppatori. Nessuna categoria di vendor è strutturalmente esente: se la compromissione avviene a monte, a livello di credenziali di publishing, le garanzie downstream diventano circolari.
L'ironia tecnica è che l'attacco targeting esplicito di tool AI e configurazioni MCP indichi una consapevolezza del threat model contemporaneo. Gli assistenti di coding e i protocolli di contesto modello stanno diventando superfici di attacco autonome: le credenziali embeddate in questi strumenti non sono più solo "segreti di sviluppo" ma vettori di accesso a infrastrutture AI-centriche.
Il pacchetto resta deprecato ma non rimosso dal registro npm: con version pinning è ancora installabile. Questa è una scelta architetturale del registro, non risolvibile dall'utente singolo. La consapevolezza che npm 12 non arresti la generazione 2 — e che l'operatore l'abbia previsto — deve informare la valutazione del rischio nelle pipeline che migrano alla nuova versione del package manager.
Domande frequenti
Perché la versione 8.18.0 è stata omessa dall'advisory Jscrambler?
Il dossier non fornisce una spiegazione. StepSecurity la documenta con timestamp 17:46 UTC; Jscrambler elenca 8.14.0, 8.16.0, 8.17.0 e 8.20.0. Il motivo dell'omissione è sconosciuto.
L'esecuzione del payload richiede privilegi di root?
No: la persistenza macOS usa ~/Library/LaunchAgents (spazio utente), e il dropper scrive in directory temporanee. L'eBPF su Linux richiede tipicamente CAP_BPF o privilegi equivalenti, ma il dossier non specifica se il payload implementi tecniche di privilege escalation.
Il codice sorgente del malware è disponibile per analisi?
No. L'analisi è condotta su binari nativi. StepSecurity segnala che l'analisi del programma eBPF embedded è ancora in corso; il contenuto esatto delle hook kernel non è ancora noto.
Fonti
- https://www.bleepingcomputer.com/news/security/hackers-backdoor-jscrambler-npm-package-with-infostealer-malware/
- https://thehackernews.com/2026/07/compromised-jscrambler-8140-npm-release.html
- https://securityboulevard.com/2026/07/jscrambler-npm-package-compromised-a-security-vendor-becomes-the-supply-chain-risk/
- https://defend.network/briefings/npm-supply-chain-zimbra-rce-android-malware-2026-07-13.html
- https://www.stepsecurity.io/blog/jscrambler-npm-package-publishes-malicious-preinstall-binary
- https://krebsonsecurity.com/2026/07/fbi-seizes-netnut-proxy-platform-popa-botnet/
- https://www.bleepingcomputer.com/
- https://www.bleepingcomputer.com/tutorials/
Jscrambler, vendor di sicurezza, diventa vettore supply chain: 5 versioni npm con infostealer Rust
Attori minacciosi hanno compromesso le credenziali npm di Jscrambler e pubblicato cinque versioni malevole del pacchetto jscrambler tra le 15:12 e le 17:53 UTC dell'11 luglio 2026. Il payload, un infostealer Rust cross-platform nascosto in un container binario con estensione .js, raccoglie credenziali da ambienti di sviluppo, cloud, tool AI e wallet crittografici. L'attacco presenta una doppia generazione tecnica: la prima sfrutta i preinstall hook, la seconda — pubblicata tre giorni dopo il rilascio di npm 12 che disabilita gli install script — si attiva tramite require(), aggirando la nuova mitigazione.
- Cinque versioni malevole (8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0) pubblicate in circa tre ore, con la 8.15.0 pulita interposta — pattern che suggerisce controllo manuale del flusso.
- Il payload è un binario nativo Rust (ELF, PE32+, Mach-O) da 7,8 MB, non JavaScript, mascherato da file .js tramite header magico custom di 5 byte.
- La generazione 2 (8.18.0, 8.20.0) bypassa
npm install --ignore-scriptsiniettando il dropper indist/index.jsattivato al primorequire(). - Capacità eBPF su Linux per hook kernel-level senza touch filesystem; persistenza via scheduled task su Windows e LaunchAgent su macOS.
Come è avvenuta la compromissione
La causa radice è confermata: credenziali npm di publishing compromesse, poi revocate da Jscrambler. Secondo la dichiarazione dell'azienda riportata da BleepingComputer, l'incidente è "limitato a quel pacchetto" e non ha coinvolto altri prodotti, incluso Webpage Integrity. Le versioni malevole non hanno alcuna corrispondenza nel repository GitHub pubblico: nessun commit, tag o pull request documenta il loro rilascio. Socket ha rilevato la versione 8.14.0 sei minuti dopo la pubblicazione; StepSecurity OSS AI Package Analyst ha assegnato il massimo suspicion score (0) già al momento del publish.
I timestamp esatti ricostruiti da StepSecurity mostrano una sequenza serrata: 8.14.0 alle 15:12, 8.16.0 alle 17:26, 8.17.0 alle 17:41, 8.18.0 alle 17:46, 8.20.0 alle 17:53 UTC. L'intervallo di circa tre ore e la presenza della 8.15.0 pulita tra la 8.14.0 e la 8.16.0 indicano un operatore che controlla attivamente il processo, non un sistema automatico a rilascio continuo. Jscrambler ha elencato quattro versioni nel proprio advisory, omettendo la 8.18.0 — un dettaglio non chiarito.
"Il payload non è JavaScript incorporato. È un binario nativo compilato in Rust... contrabbandato dentro un file con estensione .js dietro un header magico custom di 5 byte." — StepSecurity
L'architettura del payload: un container binario multi-piattaforma
Il file dist/intro.js nelle versioni malevole pesa 7,8 MB contro i 37,8 kB della versione pulita. Dietro l'estensione .js si nasconde un container gzip con tre binari nativi: ELF x86-64 per Linux, PE32+ per Windows, Mach-O arm64 per macOS. Il magic header 1B 43 53 49 01 — identico byte-per-byte in tutte e cinque le versioni — permette al dropper setup.js di identificare e decomprimere il payload corretto per l'host target.
Una volta estratto, il binario viene scritto in una directory temporanea con nome random e eseguito in modalità detached. I tre hash SHA-256 documentati da The Hacker News e StepSecurity sono: Linux fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd; Windows b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903; macOS c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd.
La doppia generazione: da preinstall a require()
Le prime tre versioni (8.14.0-8.17.0) rappresentano la generazione 1: l'attivazione avviene tramite il campo preinstall in package.json, eseguito automaticamente durante npm install. Questa è la tecnica classica di supply chain npm, ora mitigata da npm 12 rilasciato l'8 luglio 2026 con install script disabilitati di default.
La generazione 2 (8.18.0-8.20.0) risponde a questa hardening. Il dropper è inlinizzato direttamente in dist/index.js, il punto di ingresso principale del pacchetto, e si attiva al primo require("jscrambler") — operazione che avviene necessariamente quando il modulo viene importato nell'applicazione target. Come notano The Hacker News e StepSecurity, npm install --ignore-scripts non arresta questa variante: il codice malevolo è già nel file principale del modulo.
L'intervallo di tre giorni tra npm 12 e l'attacco non è casuale. L'operatore ha osservato il cambiamento di default, ha verificato che i client legacy restassero vulnerabili ai preinstall hook, e ha preparato contemporaneamente una variante resistente alla nuova configurazione. La velocità di adattamento è un indicatore di maturità operativa.
Cosa ruba e come persiste
L'infostealer bersaglia credenziali da multiple superfici di attacco. I target documentati da BleepingComputer, The Hacker News e Security Boulevard includono: ambienti di sviluppo (Git, SSH, variabili d'ambiente, token CI/CD); piattaforme cloud (AWS, Azure, GCP, Kubernetes); tool AI (Claude, Cursor, Windsurf, VS Code, Zed) con configurazioni MCP (Model Context Protocol); wallet crittografici (MetaMask, Phantom, Coinbase, Exodus, Trust); messaging aziendale (Slack, Discord, Telegram); e il password manager Bitwarden.
La capacità eBPF su Linux, rilevata da StepSecurity tramite analisi della import table, è particolarmente significativa. Il payload linka libbpf.so.1 e utilizza bpf_object__open_mem, bpf_object__load e bpf_program__attach per caricare programmi eBPF direttamente dalla memoria, senza scrivere sul filesystem. Questo consente hook a livello kernel con minima traccia forense. Su Windows la persistenza avviene tramite scheduled task nascosto con rilancio ogni minuto; su macOS tramite LaunchAgent in ~/Library/LaunchAgents. Entrambe le piattaforme implementano anti-debug: IsDebuggerPresent su Windows, sysctl/sysctlbyname con P_TRACED su macOS.
Gli indicatori di rete osservati da StepSecurity con Harden-Runner includono chiamate outbound verso archive.torproject.org e check.torproject.org, oltre agli IP 37.27.122.124 e 57.128.246.79. L'esfiltrazione avviene via TLS attraverso la rete Tor.
Cosa fare adesso
StepSecurity ha emesso l'indicazione operativa più netta: "Se hai installato una qualsiasi delle versioni jscrambler 8.14.0, 8.16.0, 8.17.0, 8.18.0 o 8.20.0: tratta l'host come compromesso." Questa raccomandazione si traduce in quattro priorità.
Prima: verificare i lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) alla ricerca delle cinque versioni malevole. La versione 8.15.0 risulta pulita, la 8.22.0 è quella raccomandata come pulita dalle fonti.
Seconda: nei sistemi dove è stata eseguita una delle versioni compromesse, effettuare rotazione completa di tutte le credenziali presenti nelle categorie target elencate dalla fonte — non solo npm, ma anche Git, cloud, CI/CD, tool AI e wallet crittografici.
Terza: controllare la presenza di persistenza OS-level: scheduled task su Windows con esecuzione minutaria non documentata, e LaunchAgent in ~/Library/LaunchAgents su macOS. L'analisi della rete outbound verso i domini Tor e gli IP indicati può confermare compromissione attiva.
Quarta: verificare che le pipeline CI/CD non riutilizzino cache o artefatti derivati da build con le versioni malevole. Il payload si attiva su require(): un'immagine container costruita con il pacchetto compromesso rimane infetta anche se il lockfile è stato successivamente corretto.
Il paradosso di un vendor di "code integrity"
Jscrambler vende prodotti di protezione client-side e integrità del codice. Il fatto che il proprio pacchetto npm sia diventato vettore di una delle supply chain attack più sofisticate del 2026 — con adattamento attivo a mitigazioni appena rilasciate — solleva questioni sul modello di trust che le toolchain di sicurezza richiedono agli sviluppatori. Nessuna categoria di vendor è strutturalmente esente: se la compromissione avviene a monte, a livello di credenziali di publishing, le garanzie downstream diventano circolari.
L'ironia tecnica è che l'attacco targeting esplicito di tool AI e configurazioni MCP indichi una consapevolezza del threat model contemporaneo. Gli assistenti di coding e i protocolli di contesto modello stanno diventando superfici di attacco autonome: le credenziali embeddate in questi strumenti non sono più solo "segreti di sviluppo" ma vettori di accesso a infrastrutture AI-centriche.
Il pacchetto resta deprecato ma non rimosso dal registro npm: con version pinning è ancora installabile. Questa è una scelta architetturale del registro, non risolvibile dall'utente singolo. La consapevolezza che npm 12 non arresti la generazione 2 — e che l'operatore l'abbia previsto — deve informare la valutazione del rischio nelle pipeline che migrano alla nuova versione del package manager.
Domande frequenti
Perché la versione 8.18.0 è stata omessa dall'advisory Jscrambler?
Il dossier non fornisce una spiegazione. StepSecurity la documenta con timestamp 17:46 UTC; Jscrambler elenca 8.14.0, 8.16.0, 8.17.0 e 8.20.0. Il motivo dell'omissione è sconosciuto.
L'esecuzione del payload richiede privilegi di root?
No: la persistenza macOS usa ~/Library/LaunchAgents (spazio utente), e il dropper scrive in directory temporanee. L'eBPF su Linux richiede tipicamente CAP_BPF o privilegi equivalenti, ma il dossier non specifica se il payload implementi tecniche di privilege escalation.
Il codice sorgente del malware è disponibile per analisi?
No. L'analisi è condotta su binari nativi. StepSecurity segnala che l'analisi del programma eBPF embedded è ancora in corso; il contenuto esatto delle hook kernel non è ancora noto.
Fonti
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.