Shai-Hulud 2.0 il malware cross-platform che minaccia npm e Maven

Nel panorama della cybersecurity del 2025, una delle minacce più sofisticate e pericolose ha preso il nome di Shai-Hulud 2.0, un malware che rappresenta l’evoluzione di quello che molti esperti considerano il più aggressivo supply chain attack mai registrato. Questa campagna ha segnato un punto di svolta nell’ambito della sicurezza informatica, dimostrando come gli attaccanti possano sfruttare simultaneamente ecosistemi diversi per massimizzare l’impatto delle loro operazioni.

Anatomia di un attacco cross-platform devastante

Shai-Hulud 2.0 si distingue per la sua capacità di compromettere simultaneamente npm e Maven Central, i due principali repository di pacchetti per JavaScript e Java. Questa strategia cross-platform ha permesso agli attaccanti di infiltrarsi in diverse catene di sviluppo contemporaneamente, amplificando esponenzialmente la portata dell’attacco.

I numeri parlano chiaro: oltre 28.000 repository compromessi e circa 11.858 segreti sensibili trafugati. Tra i pacchetti colpiti spicca il caso di org.mvnpm:posthog-node:4.18.1 su Maven Central, legato al progetto PostHog, insieme a più di 830 pacchetti npm compromessi.

L’architettura modulare del malware

La sofisticazione tecnica di Shai-Hulud 2.0 emerge chiaramente dalla sua architettura modulare, composta da due componenti principali:

• setup_bun.js: Il loader responsabile dell’installazione e avvio del runtime Bun, una piattaforma JavaScript alternativa a Node.js utilizzata per mascherare ed eseguire il payload principale
• bun_environment.js: Il payload che effettua l’esfiltrazione vera e propria di credenziali locali, token GitHub, chiavi SSH e segreti cloud di AWS, Azure e GCP

Meccanismi di infezione e propagazione

L’attacco sfrutta strategicamente la fase di preinstall dei pacchetti, un momento critico in cui il codice malevolo può essere eseguito prima ancora che lo sviluppatore si renda conto della compromissione. Questa tempistica permette al malware di infiltrarsi sia negli ambienti di sviluppo locali sia nelle pipeline CI/CD aziendali.

Una delle caratteristiche più preoccupanti di Shai-Hulud 2.0 è la sua capacità di diffondersi automaticamente senza comandi esterni. Il malware opera in modo autonomo, creando repository GitHub pubblici ad hoc per l’esfiltrazione dei dati e implementando meccanismi di persistenza attraverso:

• Creazione di runner self-hosted GitHub
• Inserimento di workflow GitHub Actions malevoli
• Capacità di esecuzione remota di comandi

Funzioni distruttive come ultima risorsa

Particolarmente allarmante è la presenza di funzioni distruttive che si attivano quando il malware non riesce ad accedere ai servizi compromessi. In questi casi, il software malevolo procede alla cancellazione di dati locali, inclusa la home directory dell’utente, trasformando l’attacco da una semplice esfiltrazione di dati a una potenziale operazione di sabotaggio.

Il caso PostHog: quando la fiducia diventa vulnerabilità

Il caso del pacchetto PostHog rappresenta un esempio emblematico di come questa campagna abbia sfruttato la fiducia negli ecosistemi ufficiali. PostHog, essendo un progetto legittimo e ampiamente utilizzato per l’analisi dei prodotti, ha fornito la copertura perfetta per gli attaccanti.

La compromissione di pacchetti apparentemente legittimi sottolinea una verità scomoda: anche i repository ufficiali come npm e Maven Central possono diventare vettori di attacco quando non vengono implementati controlli di sicurezza adeguati.

Impatti sulla supply chain globale

Le conseguenze di Shai-Hulud 2.0 si estendono ben oltre i singoli sviluppatori colpiti. L’attacco ha evidenziato vulnerabilità sistemiche che interessano:

• Sicurezza delle credenziali: Token e chiavi di accesso compromesse per servizi cloud critici
• Operatività di sviluppo: Interruzione dei flussi di lavoro e necessità di revisione completa delle dependency
• Fiducia nell’ecosistema: Erosione della fiducia nei repository ufficiali e nei processi di vetting dei pacchetti

L’effetto domino sulle organizzazioni

Le organizzazioni che utilizzano pacchetti compromessi si sono trovate a dover affrontare non solo la pulizia dei sistemi infetti, ma anche la revoca e rigenerazione di masse di credenziali. Questo processo, oltre ad essere costoso in termini di tempo e risorse, ha esposto molte aziende a finestre di vulnerabilità durante la fase di remediation.

Lezioni apprese e strategie di difesa

Shai-Hulud 2.0 ha dimostrato l’urgente necessità di ripensare gli approcci alla sicurezza della supply chain software. Alcune delle lezioni più importanti includono:

• Monitoring continuo: Implementazione di sistemi di monitoraggio che possano rilevare comportamenti anomali durante l’installazione dei pacchetti
• Sandboxing delle dependency: Isolamento dell’esecuzione dei pacchetti durante le fasi di build e test
• Audit regolari: Revisione periodica delle dependency utilizzate nei progetti
• Controlli di integrità: Verifica della firma digitale e dell’integrità dei pacchetti prima dell’installazione

La campagna Shai-Hulud 2.0 rappresenta un momento di svolta nella storia degli attacchi alla supply chain software. La sua sofisticazione tecnica, combinata con l’approccio cross-platform e la capacità di operare autonomamente, ha ridefinito il panorama delle minacce per il 2025. Questo evento sottolinea l’importanza critica di implementare controlli di sicurezza robusti non solo nei nostri sistemi, ma anche negli ecosistemi di terze parti di cui ci fidiamo quotidianamente. La lezione più importante è che la sicurezza della supply chain non può più essere considerata responsabilità esclusiva dei maintainer dei repository: deve diventare una responsabilità condivisa che coinvolge sviluppatori, organizzazioni e fornitori di piattaforme in un approccio olistico alla protezione del software.