Pacchetti software npm compromessi in un attacco supply chain

Miasma: worm nei pacchetti npm di Red Hat, sviluppatori nel mirino

A cura di:Redazione Ore

Per secoli si è creduto che le pestilenze viaggiassero nell’aria: un miasma, un alito corrotto che si insinuava nei polmoni senza volto né origine, e contaminava prima ancora di farsi vedere. Un’idea sbagliata sulla medicina, ma un’intuizione perfetta sul contagio.

Chi ha battezzato l’ultima variante del worm Shai-Hulud lo sapeva: i repository che il malware genera per trafugare i dati recano una sola, eloquente descrizione, “Miasma: The Spreading Blight“. Il flagello dilagante. Non un nome scelto a caso, ma un manifesto. Perché è esattamente così che agisce: una corruzione che si respira con la filiera del software, si diffonde a ogni installazione come un fiato malato e si porta via credenziali, ambienti di build e strumenti di sviluppo prima che lo sviluppatore si accorga del contagio.

Attacco supply chain npm, Red Hat conferma l’accaduto

Un nuovo attacco supply chain npm ha colpito i pacchetti pubblicati sotto il namespace ufficiale @redhat-cloud-services : il 1° giugno 2026 i ricercatori di Wiz Research hanno identificato almeno 32 pacchetti compromessi con una variante del worm Shai-Hulud ribattezzata Miasma, dal nome dei repository di esfiltrazione creati dal malware con la descrizione “Miasma: The Spreading Blight”. I pacchetti coinvolti totalizzano circa 80.000 download settimanali secondo la stima di Wiz, circa 117.000 secondo i conteggi di Aikido ripresi dalla stampa di settore (le stime divergono per metodologia); le versioni compromesse accertate a fine ricognizione sono 96.

Red Hat ha confermato l’accaduto a The Register per bocca di un portavoce: i pacchetti malevoli sono stati rimossi dal registro npm e, secondo l’azienda, erano «strettamente limitati allo sviluppo interno»; al momento «non è stato identificato alcun impatto su ambienti di clienti o partner né sui sistemi di produzione Red Hat». L’indagine è però ancora in corso e Wiz classifica la campagna come minaccia attiva: il quadro va quindi considerato in evoluzione.

Come è avvenuta la compromissione

Il punto di ingresso accertato è l’account GitHub di un dipendente Red Hat. Secondo la ricostruzione di Wiz, l’account compromesso ha inviato commit orfani a tre repository dell’organizzazione RedHatInsights (frontend-components, javascript-clients e platform-frontend-ai-toolkit), aggirando la code review, in due ondate distinte nella stessa giornata.

I commit contenevano un workflow GitHub Actions minimale che si attivava su qualsiasi push: richiedeva un token OIDC con permesso id-token: write , eseguiva un payload offuscato e pubblicava su npm le versioni avvelenate dei pacchetti, complete di attestazioni di provenienza SLSA formalmente valide. È un dettaglio rilevante: la firma di provenienza, nata proprio per dare garanzie sull’integrità della filiera, è stata prodotta dal flusso di build legittimo e non ha quindi offerto alcuna protezione.

Le versioni compromesse contenevano uno script preinstall che eseguiva automaticamente un file JavaScript pesantemente offuscato al momento dell’installazione del pacchetto, prima ancora che lo sviluppatore ne importasse il codice.

Cosa ruba Miasma e cosa cambia rispetto a Shai-Hulud

Il payload è derivato dal codice di Mini Shai-Hulud, il worm per npm che il gruppo criminale TeamPCP ha reso pubblico nelle settimane scorse. Le analisi convergenti di Wiz, Socket e altri vendor descrivono un ladro di credenziali ad ampio spettro: secret di GitHub Actions, token npm, credenziali cloud, materiale Kubernetes e Vault, chiavi SSH, credenziali Git e altri file sensibili presenti sulla macchina infetta.

I dati raccolti vengono compressi, cifrati ed esfiltrati su un doppio canale: quello primario è una POST HTTPS verso un endpoint mascherato da chiamata all’API di Anthropic (api.anthropic[.]com:443/v1/api, un percorso che non corrisponde all’API reale), un travestimento studiato per confondersi con il normale traffico verso i fornitori AI; in caso di fallimento il malware ripiega sulla Contents API di GitHub, committando i risultati cifrati in repository marcati con la descrizione “Miasma: The Spreading Blight”.

È qui che Miasma si comporta da worm in senso proprio: secondo l’analisi di StepSecurity, i token npm rubati vengono riusati per ripubblicare in autonomia versioni backdoor dei pacchetti a cui l’account vittima ha accesso, sfruttando il parametro bypass_2fa di npm per scavalcare anche l’autenticazione a due fattori. Ogni macchina infetta può così seminare da sola l’ondata successiva, senza ulteriore intervento dell’attaccante.

Due le novità principali rispetto alle ondate precedenti. La prima è l’aggiunta di collector dedicati alle identità cloud di Google Cloud e Microsoft Azure: non più solo furto di secret, ma censimento di tutte le identità a cui la macchina infetta ha accesso, segnale di un interesse crescente per l’accesso diretto agli ambienti cloud. La seconda è la generazione di un payload cifrato unico per ogni infezione, che rende gli indicatori di compromissione basati su hash validi solo per la singola versione di pacchetto e complica il lavoro di rilevamento.

Il malware mostra inoltre una notevole attenzione all’ambiente in cui gira: verifica la presenza di soluzioni di endpoint protection prima di agire, evita l’esecuzione sui sistemi configurati in lingua russa e stabilisce persistenza negli strumenti di sviluppo, iniettando un hook di sessione nella configurazione di Claude Code e un task con avvio automatico all’apertura della cartella nei progetti Visual Studio Code.

Attribuzione incerta

Le tattiche osservate coincidono con quelle di TeamPCP, il gruppo dietro le campagne Shai-Hulud. Proprio perché TeamPCP ha reso open source i propri strumenti, però, tutti i ricercatori coinvolti invitano alla prudenza: la sovrapposizione di tecniche non basta per un’attribuzione definitiva e non si può escludere un imitatore che riutilizza il codice pubblico. Secondo OX Security, citata da The Hacker News, la prima traccia della stringa “Miasma” risale al 29 maggio, indizio di una fase di test precedente all’attacco.

Cosa fare subito

Le organizzazioni che hanno installato una delle versioni compromesse devono assumere la compromissione: isolare gli host coinvolti, rimuovere le versioni malevole e ruotare tutte le credenziali potenzialmente esposte, inclusi token GitHub e npm, chiavi SSH e credenziali cloud. Socket sottolinea che disinstallare il pacchetto o cancellare la cartella node_modules non è una bonifica sufficiente, vista la persistenza negli strumenti di sviluppo: vanno verificati anche i file di configurazione di Claude Code, VS Code e i workflow GitHub. Per le pipeline CI/CD è raccomandata la sospensione delle esecuzioni interessate e l’invalidazione degli artefatti di build prodotti nella finestra di esposizione.

L’episodio si inserisce in un’ondata di attacchi alla supply chain software che negli ultimi due mesi ha toccato progetti come TanStack, Nx Console e migliaia di repository GitHub con la campagna Megalodon, al punto da spingere la statunitense CISA a pubblicare un alert dedicato il 28 maggio. La lezione per chi sviluppa software è ormai consolidata, anche alla luce degli obblighi in arrivo con il Cyber Resilience Act: dependency pinning, allowlist delle dipendenze, generazione di SBOM e monitoraggio degli ambienti di build non sono più buone pratiche opzionali, ma il perimetro minimo di difesa di una catena di fornitura sotto attacco costante.

Fonti

Condividi sui Social Network:

Ultimi Articoli