L'ecosistema JavaScript/npm sta affrontando un nuovo punto di riferimento nelle minacce alla catena di approvvigionamento con la ricomparsa di Shai-Hulud 2.0 il 24 novembre 2025. Il worm autopropagante prende di mira specificamente i manutentori open source e i pacchetti che pubblicano. Questa nuova variante segna il passaggio da pacchetti dannosi isolati a un meccanismo di infezione coordinato e automatizzato.
L'impatto è già grave. Centinaia di pacchetti npm e decine di migliaia di repository GitHub sono stati colpiti, creando un "raggio d'azione" senza precedenti per un attacco alla catena di fornitura JavaScript. Per i lettori che hanno familiarità con l'analisiOPSWATsu Shai-Hulud 1.0, la versione 2.0 espande notevolmente le capacità e la portata operativa del worm: esecuzione anticipata, propagazione più ampia e maggiore resistenza alle misure correttive standard, elevandolo da minaccia preoccupante a incidente a livello di ecosistema completo.
Shai-Hulud 2.0 Informazioni rapide
- Worm autopropagante: Shai-Hulud 2.0 ruba le credenziali GitHub, si ricompone e si ripubblica nell'intero portafoglio npm di un manutentore.
- Diffusione massiccia:oltre 700 pacchetti npm infetti, oltre 25.000 repository GitHub, 500 manutentori colpiti; oltre 1.000 nuovi repository aggiunti ogni 30 minuti (Wiz).
- Impatto cross-ecosistema: osservato anche in Maven/Java tramite mirroring automatico da npm a Maven.
- Rischi principali: esposizione CI/CD, compromissione dei segreti, esecuzione durante l'installazione e registri compromessi.
- Difesa: accuratezza SBOM, verifica della provenienza, monitoraggio del runtime e rigorosa igiene dei token/segreti.
Portata ed escalation: quanto è esteso il danno?
La portata e la velocità di diffusione di Shai-Hulud 2.0 hanno superato qualsiasi altro incidente verificatosi recentemente nella catena di approvvigionamento. Quello che era iniziato come un attacco mirato a npm si è rapidamente trasformato in un'infezione sistemica e multipiattaforma che ha colpito migliaia di progetti e centinaia di manutentori.
A differenza dei tipici malware npm, che solitamente coinvolgono un singolo pacchetto trojanizzato, Shai-Hulud 2.0 si comporta come un worm. Dopo aver compromesso uno sviluppatore, ruba le credenziali GitHub, si riconfeziona e ripubblica l'intero set di pacchetti del manutentore, trasformando ogni vittima in un nuovo punto di distribuzione. Il risultato è una diffusione rapida ed esponenziale in tutto l'ecosistema.
Pacchetti compromessi
Centinaia di pacchetti npm sono stati compromessi. Tra questi figurano progetti di grande visibilità gestiti da organizzazioni consolidate, che amplificano l'esposizione a valle.
Diffusione rapida ed esponenziale
È stato osservato che il worm genera oltre 1.000 nuovi repository GitHub dannosi ogni 30 minuti (Wiz), alimentati dalla pubblicazione automatizzata delle credenziali rubate. Ogni nuova vittima diventa un nodo di propagazione, moltiplicando l'impatto totale ad ogni ciclo.
Segreti svelati
La componente relativa al furto di credenziali di Shai-Hulud 2.0 si sta rivelando particolarmente dannosa. Tra i segreti verificati trapelati figurano oltre 1.500 credenziali e token relativi alle principali piattaforme: GitHub, AWS, Google Cloud e Azure.
Questo volume di token sensibili rappresenta un compromesso ampio e multi-cloud con il potenziale per uno sfruttamento a lungo termine.
Interventi di bonifica
Fortunatamente, diversi gestori di alto profilo come Zapier, PostHog e Postman hanno già ripreso il controllo dei propri pacchetti. Le versioni dannose sono state rimosse da npm e molti repository interessati sono stati recuperati o ripuliti.
Tuttavia, l'incidente è ancora in evoluzione. Anche con una rapida riparazione, le organizzazioni devono continuare a monitorare lo stato di salute delle dipendenze, le pipeline CI e gli account GitHub per individuare eventuali segni di ulteriori fughe di credenziali o ripubblicazioni automatizzate.
Impatto cross-ecosistema: npm → Maven/Java
In particolare, questa tendenza ha influenzato anche altri ecosistemi come Maven/Java attraverso la conversione automatizzata degli artefatti da npm a Maven (JFrog).
-
Sebbene npm rimanga l'obiettivo principale di Shai-Hulud 2.0, questa ondata ha dimostrato il rischio di propagazione tra ecosistemi, in particolare nei progetti Java/Maven. I ricercatori di sicurezza hanno identificato l'artefatto Maven dannoso:
org.mvnpm:posthog-node:4.18.1che contiene lo stesso payload (setup_bun.jsebun_ambiente.js) presenti nei pacchetti npm compromessi (Le notizie sugli hacker) .
- Meccanismo: strumenti di bridging automatizzati ricostruiscono i pacchetti npm come artefatti Maven per progetti Java. I team che non utilizzano direttamente Node.js potrebbero essere esposti se i loro progetti si basano su questi artefatti mirrorati.
Ciò dimostra il rischio indipendente dall'ecosistema degli attacchi alla catena di approvvigionamento. Anche i progetti che non utilizzano direttamente npm possono ereditare il rischio attraverso strumenti automatizzati.
Shai-Hulud 2.0 dimostra che i moderni worm della catena di approvvigionamento sono minacce multistadio sensibili all'ambiente: si adattano ai computer degli sviluppatori e alle pipeline CI/CD, raccolgono credenziali sia come payload che come meccanismo di propagazione e includono comportamenti di fallback per garantire la diffusione o l'impatto distruttivo. Il rilevamento richiede il monitoraggio del comportamento di runtime in tutte le fasi, non solo l'analisi statica del codice.
Meccanica tecnica: come funziona il verme
| Palcoscenico | Cosa succede |
|---|---|
| 1. Accesso iniziale e implementazione | Gli aggressori sfruttano gli account compromessi dei gestori npm per distribuire pacchetti contenenti setup_bun.js e bun_ambiente.js, eseguito automaticamente tramite un preinstallare collegamento tra macchine degli sviluppatori e pipeline CI/CD. |
| 2. Inizializzazione silenziosa del runtime | Il caricatore rileva l'ambiente host, inizializza il runtime Bun ed esegue il payload in modo silenzioso in background per far sembrare normali le installazioni. |
| 3. Impronte digitali ambientali ed escalation dei privilegi | Il payload identifica le piattaforme CI, tenta l'accesso root senza password tramite Docker sui runner Linux e può modificare le regole DNS o iptables per controllare i flussi di rete. |
| 4. Raccolta di credenziali e segreti | Il payload raccoglie variabili ambientali e chiavi cloud, esegue TruffleHog per individuare segreti locali, estrae credenziali AWS/Azure/GCP e inserisce flussi di lavoro temporanei per estrarre segreti GitHub. |
| 5. Esfiltrazione e persistenza | I dati rubati vengono codificati con tripla codifica base64 e caricati in un nuovo repository nell'account della vittima, mentre la persistenza viene stabilita tramite un runner e un flusso di lavoro self-hosted dannosi. |
| 6. Propagazione dei worm (replicazione) | Utilizzando token npm rubati, il worm clona i pacchetti della vittima, inietta file e hook dannosi, aumenta le versioni e li ripubblica per diffondersi in modo autonomo. |
| 7. Fallback distruttivo | Se non è possibile raccogliere alcuna credenziale, il worm attiva una routine distruttiva che cancella in modo sicuro la directory home dell'utente. |
Rischi CI/CD evidenziati dall'incidente PostHog
La violazione di PostHog dimostra la sottigliezza dell'esposizione CI/CD:
- Richieste di pull dannose hanno sfruttato pull_request_target in GitHub Actions.
- È stato sottratto un bot PAT, che ha poi consentito la pubblicazione di SDK npm trojanizzati.
I flussi di lavoro CI/CD, anche quelli automatizzati, sono superfici di attacco ad alto rischio. Limitate gli script, riducete al minimo l'esposizione dei token e applicate credenziali a breve durata.
Limiti delle difese tradizionali
- Il pinning delle dipendenze potrebbe non riuscire a causa delle dipendenze transitive.
- Gli scanner SCA statici non sono in grado di rilevare codice trojanizzato appena pubblicato sotto nomi di pacchetti legittimi.
- L'uso improprio dei token tramite pipeline CI/CD significa che anche i repository interni sono a rischio.
Come utilizzare SBOM e Supply Chain come difesa
Gli strumenti SBOM e della catena di fornitura possono fornire:
- Trasparenza delle dipendenze: tiene traccia delle dipendenze dirette e transitive con metadati relativi alla versione e al responsabile della manutenzione.
- Verifica della provenienza: identifica modifiche impreviste ai pacchetti o manutentori sconosciuti.
- Monitoraggio delle credenziali e dei segreti: rileva tentativi di esfiltrazione o token utilizzati in modo improprio.
- Approfondimenti comportamentali: monitora l'accesso alle risorse o modelli di esecuzione insoliti durante le installazioni.
Sebbene non sia una soluzione miracolosa, combinare SBOM con il monitoraggio continuo rafforza le difese contro gli attacchi di tipo worm.
OPSWAT e MetaDefender Software Supply ChainChain™
La tecnologia OPSWAT esegue la scansione del repository del codice sorgente e rileva il pacchetto npm sha1-hulud dannoso.
MetaDefender Software Supply Chain fornisce un quadro più completo e rileva il pacchetto sha1-hulud compromesso.
Metascan Multiscanning aggiunge livelli di difesa per rilevare il malware:
Azioni immediate raccomandate
- Ruota le credenziali: PAT GitHub, token npm, chiavi SSH, credenziali cloud; abilita l'autenticazione a più fattori (MFA).
- Rimuovi i pacchetti compromessi: svuota la cache npm, node_modules e fissa le versioni note come pulite.
- Audit GitHub e CI/CD: ricerca nuovi repository, flussi di lavoro e commit sospetti.
- Rafforzare le pipeline: limitare gli script del ciclo di vita, limitare l'accesso alla rete in uscita e ridurre al minimo l'ambito dei token.
- Monitoraggio continuo: trattare le dipendenze e creare pipeline come parte della superficie di attacco critica.
Punti di forza
Le minacce alla catena di approvvigionamento sono indipendenti dall'ecosistema
La diffusione di Shai-Hulud 2.0 in Maven/Java tramite il bridging da npm a Maven dimostra che gli attacchi alla catena di fornitura possono superare i confini linguistici ed ecosistemici. Anche i progetti che non utilizzano direttamente npm possono essere esposti se vengono utilizzati strumenti di bridging automatizzati.
L'igiene delle credenziali è fondamentale
I token rubati (GitHub, npm, cloud) consentono la propagazione e l'accesso ad ambienti sensibili. Utilizzate token a breve durata e con ambito limitato, applicate l'autenticazione a più fattori (MFA) e ruotate le credenziali immediatamente dopo qualsiasi sospetto di compromissione. Utilizzate strumenti automatizzati di scansione dei segreti per accelerare il processo.
Supply Chain olistica Supply Chain è obbligatoria
Affidarsi esclusivamente alla scansione SCA statica o al pinning delle versioni non è sufficiente. Combina la visibilità SBOM, la scansione multipla del malware e la protezione dei token/segreti per ridurre l'esposizione in tutti gli ecosistemi. Scopri MetaDefender Software Supply Chain
Sei pronto a proteggere la tua catena di fornitura software e prevenire gli attacchi informatici con soluzioni personalizzate e perfettamente integrate?
