Malware Shai Hulud v2

La seconda ondata dell'attacco alla supply chain Shai-Hulud ha ora raggiunto l'ecosistema Maven, in seguito alla compromissione di oltre 830 pacchetti nel registro npm. I ricercatori hanno identificato un pacchetto Maven Central, org.mvnpm:posthog-node:4.18.1, che contiene gli stessi componenti dannosi dei precedenti attacchi npm: il loader setup_bun.js e il payload bun_environment.js. Attualmente, questo è l'unico pacchetto Java interessato.

In particolare, il pacchetto Maven non è stato pubblicato da PostHog. È stato invece generato tramite un processo mvnpm automatizzato che ricostruisce i pacchetti npm come artefatti Maven. Maven Central ha confermato che tutte le copie mirror sono state eliminate il 25 novembre 2025 e che sono in fase di implementazione ulteriori misure di protezione per impedire la ripubblicazione di componenti npm compromessi.

Impatto globale degli sviluppatori e obiettivi di attacco

Questa ultima ondata prende di mira gli sviluppatori di tutto il mondo, con l'obiettivo di rubare dati sensibili come:

• chiavi API
• Credenziali cloud
• token npm e GitHub

Facilita inoltre una compromissione più profonda della supply chain, in modo simile a un worm e autoreplicandosi. Questa iterazione di Shai-Hulud è più furtiva, aggressiva e distruttiva della variante iniziale di settembre. Compromettendo gli account dei manutentori di NPM, gli aggressori possono pubblicare pacchetti trojanizzati che creano backdoor sui computer degli sviluppatori e analizzano automaticamente i segreti da esfiltrare nei repository GitHub.

Come funziona il malware: doppi flussi di lavoro e tecniche stealth

L'attacco sfrutta due flussi di lavoro dannosi:

• Registrazione del runner auto-ospitato: consente l'esecuzione di comandi arbitrari ogni volta che viene aperta una discussione su GitHub.
• Flusso di lavoro per la raccolta dei segreti: raccoglie sistematicamente le credenziali e le invia a GitHub.
• I principali miglioramenti di Shai-Hulud v2 includono:
• Utilizzo del runtime Bun per nascondere la logica di base
• Estensione del limite di infezione da 20 a 100 confezioni
• Repository di esfiltrazione randomizzati su GitHub per eludere il rilevamento

Finora sono stati colpiti oltre 28.000 repository, a dimostrazione della portata e della segretezza della campagna.

Vulnerabilità sfruttate e meccanismi della catena di fornitura

Gli autori delle minacce hanno sfruttato le configurazioni errate di CI nei flussi di lavoro di GitHub Actions, in particolare nei trigger pull_request_target e workflow_run. Un singolo flusso di lavoro configurato in modo errato può trasformare un repository nel "paziente zero", consentendo la rapida propagazione di codice dannoso.

L'attacco ha preso di mira progetti associati ad AsyncAPI, PostHog e Postman, proseguendo una campagna più ampia iniziata con l'attacco S1ngularity dell'agosto 2025, che ha avuto un impatto su diversi pacchetti Nx su npm.

Le ricadute: segreti trapelati e rischio sistemico

L'analisi della campagna mostra:

• Centinaia di token di accesso GitHub e credenziali cloud da AWS, Google Cloud e Microsoft Azure sono stati sottratti.
• Sono stati caricati su GitHub oltre 5.000 file con segreti.
• Degli 11.858 segreti univoci identificati in 4.645 repository, 2.298 erano ancora validi e pubblicamente esposti al 24 novembre 2025.

Ciò dimostra come un singolo manutentore compromesso possa innescare un effetto a cascata, infettando migliaia di applicazioni downstream.

Raccomandazioni per gli sviluppatori

Per ridurre l'esposizione, gli sviluppatori dovrebbero:

• Ruota tutte le chiavi API, i token e le credenziali
• Controlla e rimuovi le dipendenze compromesse
• Reinstallare le versioni pulite del pacchetto
• Rafforza gli ambienti CI/CD con accesso con privilegi minimi, scansione segreta e applicazione automatizzata delle policy

Shai-Hulud sottolinea che la moderna supply chain del software rimane altamente vulnerabile. Gli aggressori continuano a sfruttare le lacune nelle modalità di pubblicazione, pacchettizzazione e distribuzione del software open source, spesso senza fare affidamento sulle vulnerabilità zero-day. La difesa più efficace richiede di ripensare il modo in cui il software viene sviluppato, condiviso e utilizzato.