Una nuova variante del worm “Mini Shai-Hulud” sta colpendo l’ecosistema open source attraverso una delle campagne supply chain più sofisticate osservate finora nei repository npm e PyPI. Secondo le analisi pubblicate da diverse società di cybersecurity, l’attacco ha coinvolto almeno 172 pacchetti e oltre 400 versioni malevole distribuite tramite pipeline CI/CD legittime, riuscendo persino a superare i sistemi moderni di attestazione crittografica della provenance software.
L’aspetto più critico dell’operazione riguarda il fatto che molti dei pacchetti compromessi risultavano firmati con attestazioni SLSA Build Level 3 e Sigstore perfettamente valide. In pratica, i pacchetti apparivano autentici anche ai sistemi di verifica progettati per garantire l’integrità della supply chain software. Questo rende la campagna particolarmente significativa perché dimostra che la provenance crittografica, da sola, non basta più a garantire che un pacchetto sia realmente sicuro.
Il worm ha colpito namespace molto utilizzati nell’ecosistema JavaScript e Python, inclusi pacchetti collegati a TanStack, Mistral AI, OpenSearch, Guardrails AI e altri ambienti enterprise e AI-oriented. Alcuni dei componenti coinvolti registrano decine di milioni di download settimanali, aumentando enormemente il potenziale impatto dell’attacco.
Dal punto di vista tecnico, il meccanismo di compromissione è particolarmente avanzato. Gli attaccanti non hanno semplicemente rubato credenziali di maintainer o pubblicato pacchetti fake con nomi simili a quelli originali, tecnica tipica del typosquatting. In questo caso il malware ha sfruttato vulnerabilità nei workflow GitHub Actions, combinando pull_request_target, cache poisoning e abuso dei token OIDC utilizzati per il trusted publishing automatico verso npm.
Secondo le ricostruzioni disponibili, gli attaccanti sarebbero riusciti a eseguire codice direttamente all’interno dei runner CI/CD ufficiali dei progetti colpiti. Una volta ottenuto accesso alla pipeline, il worm ha potuto generare pubblicazioni apparentemente legittime, complete di provenance valida e firme corrette. In altre parole, la pipeline stessa è diventata il vettore di distribuzione del malware.
Il payload distribuito dai pacchetti compromessi include componenti di credential harvesting estremamente aggressivi. Le analisi parlano di malware capaci di leggere token GitHub, credenziali cloud, chiavi AWS, segreti CI/CD, token npm, SSH key e perfino configurazioni locali di strumenti AI e ambienti di sviluppo. Alcune varianti cercano informazioni in oltre cento percorsi differenti all’interno dei sistemi compromessi.
Un elemento particolarmente preoccupante riguarda la capacità di auto-propagazione del worm. Mini Shai-Hulud viene infatti descritto come un vero worm supply-chain: una volta ottenuti token o accessi CI/CD da un maintainer, il malware enumera automaticamente tutti i pacchetti pubblicabili associati a quell’account e tenta di diffondere versioni compromesse anche su altri progetti. Questo consente all’infezione di espandersi rapidamente attraverso ecosistemi open source interconnessi.
Le analisi pubblicate mostrano inoltre un’evoluzione continua della famiglia Shai-Hulud rispetto alle campagne osservate tra il 2025 e l’inizio del 2026. Le nuove varianti includono meccanismi di persistenza, comunicazioni cifrate, esfiltrazione multi-canale e perfino routine distruttive. Alcuni report indicano la presenza di codice in grado di cancellare directory locali tramite comandi distruttivi nel caso in cui vengano rilevati tentativi di revoca dei token rubati.
La campagna evidenzia anche un cambiamento importante nel panorama della sicurezza software. Negli ultimi anni molte organizzazioni hanno investito in strumenti SBOM, firma dei pacchetti, provenance crittografica e trusted publishing per proteggere la supply chain open source. L’attacco Shai-Hulud dimostra però che, se un attaccante riesce a compromettere direttamente la pipeline CI/CD legittima, tutte queste verifiche possono risultare formalmente corrette pur distribuendo codice malevolo.
Per questo motivo, diversi ricercatori stanno sottolineando la necessità di affiancare ai sistemi di provenance controlli comportamentali runtime, monitoraggio dei workflow CI/CD, segmentazione delle pipeline e limitazioni molto più rigide sui permessi OIDC associati ai processi di pubblicazione automatica. L’idea emergente è che la sicurezza della supply chain non possa più basarsi soltanto sull’autenticità della build, ma debba includere anche verifiche sul comportamento effettivo del codice e sull’integrità dell’intero ambiente di build.