La saga di Shai-Hulud, una delle campagne di attacco alla supply chain del software più persistenti del 2026, non accenna a fermarsi. I ricercatori hanno documentato nuove ondate che, sotto i nomi in codice Miasma e Hades, hanno colpito oltre un centinaio di pacchetti negli ecosistemi npm e PyPI e che, per la prima volta, hanno cominciato a propagarsi anche all'ecosistema Go. Un'estensione che alza l'asticella del rischio per chiunque sviluppi software attingendo a librerie open source.

Da Shai-Hulud a Miasma: l'evoluzione della minaccia

Il marchio di fabbrica di questa famiglia è la capacità di comportarsi come un worm: una volta che il codice malevolo finisce nell'ambiente di uno sviluppatore o in una pipeline di build, cerca di replicarsi pubblicando nuovi pacchetti infetti a nome della vittima, in un effetto a catena che amplifica rapidamente la diffusione. Le varianti più recenti si firmano letteralmente all'interno del payload: l'ondata che ha colpito decine di pacchetti del namespace @redhat-cloud-services su npm conteneva la stringa "Miasma: The Spreading Blight", mentre il filone parallelo su PyPI si identificava come "Hades – The End for the Damned".

Complessivamente i ricercatori hanno isolato centinaia di artefatti malevoli tra npm e PyPI, a riprova di una campagna industrializzata più che di un colpo isolato. Tra le tecniche osservate figurano l'avvelenamento del registro npm, l'esecuzione di codice in fase di installazione tramite il file binding.gyp, payload JavaScript ospitati con strumenti di build moderni, infrastrutture di "dead-drop" su GitHub, il furto dei segreti delle GitHub Actions e l'esfiltrazione cifrata delle credenziali.

Il salto verso Go e GitHub Actions

La novità più rilevante dell'ultima ondata, concentrata in una finestra ristretta intorno al 24 giugno, è il superamento dei confini di npm. Oltre a colpire pacchetti come quelli di LeoPlatform e RStreams, la campagna ha abusato dei flussi di lavoro delle GitHub Actions e ha compromesso un modulo Go, legato al progetto Verana Blockchain. È un segnale importante: gli attaccanti non si limitano più a un singolo gestore di pacchetti, ma cercano di colonizzare in parallelo più filiere di distribuzione del codice, sfruttando il fatto che un'unica credenziale rubata può aprire le porte a interi insiemi di repository e automazioni.

Particolarmente insidioso è il furto dei segreti delle pipeline CI/CD: token, chiavi API e credenziali cloud salvati come "secret" nelle GitHub Actions sono esattamente ciò che serve per firmare nuovi pacchetti, pubblicare release fraudolente e muoversi lateralmente verso le risorse cloud dell'organizzazione.

Come proteggersi

Per chi sviluppa software, le contromisure passano da un'igiene rigorosa delle dipendenze. È opportuno bloccare le versioni dei pacchetti (lockfile e versioni esatte anziché intervalli aperti), evitare aggiornamenti automatici verso release appena pubblicate e introdurre un periodo di "quarantena" prima di adottare nuove versioni. Sul fronte delle pipeline, conviene disabilitare gli script di post-installazione quando non strettamente necessari, applicare il principio del privilegio minimo ai token delle GitHub Actions, ruotare con frequenza i segreti e attivare meccanismi di rilevamento per pubblicazioni anomale a proprio nome. Verificare gli indicatori di compromissione diffusi dai ricercatori e controllare i log di npm e del proprio account GitHub alla ricerca di pubblicazioni non autorizzate è il primo passo per capire se si è stati toccati da questa campagna.