Miasma Worm: l'attacco AI che ha infettato i repository Microsoft su GitHub — Guida per sviluppatori e PMI

Il 5 giugno 2026, GitHub ha disabilitato 73 repository appartenenti a quattro organizzazioni Microsoft — Azure, Azure-Samples, Microsoft e MicrosoftDocs — dopo che un commit malevolo era stato inserito nel repository Azure/durabletask. Non si trattava di un attacco diretto a Microsoft, ma dell'ultima propagazione del worm Miasma, che in circa un mese ha attraversato l'ecosistema npm, i repository Red Hat e le pipeline CI/CD di alcune delle più grandi organizzazioni tecnologiche al mondo. È la prima campagna malware progettata per usare gli AI coding agent — Claude Code, Gemini CLI, Cursor e Copilot — come canale di propagazione automatica.

Per uno sviluppatore italiano, che lavora in una PMI o in una grande azienda, la domanda non è se il prossimo bersaglio sarà uno dei propri repository, ma cosa fare per non diventarlo. Miasma ha cambiato le regole del gioco: non serve più eseguire un installer o installare un pacchetto per essere infettati — basta aprire un repository in un editor potenziato dall'AI. Questo articolo offre una guida concreta per comprendere la minaccia, ispezionare il proprio ambiente e adottare contromisure efficaci.

La cronologia dell'attacco: da Red Hat a Microsoft in 35 giorni

Il worm Miasma non è apparso dal nulla. È l'evoluzione di una famiglia di malware — Shai-Hulud — osservata per la prima volta a settembre 2025 come il primo malware auto-replicante nell'ecosistema npm. Una variante ridotta, Mini Shai-Hulud, è stata rilasciata pubblicamente dal gruppo TeamPCP a metà maggio 2026, fornendo di fatto un toolkit open-source che Miasma ha poi ampliato e reso operativo su scala molto più vasta.

La campagna Miasma si è sviluppata in ondate successive e sempre più sofisticate:

• 22 maggio 2026: un attaccante con accesso push all'organizzazione GitHub Laravel-Lang riscrive ogni tag Git di diversi pacchetti Composer in una finestra di 15 minuti. È il primo segnale di una campagna coordinata che prende di mira la supply chain open-source.
• 1 giugno 2026 (Ondata 1): vengono pubblicate versioni malevole di 32 pacchetti sotto lo scope npm @redhat-cloud-services, per un totale di oltre 116.000 download settimanali coinvolti. Il payload si attiva tramite script preinstall in package.json.
• 1-2 giugno 2026 (Ondata 2): la campagna evolve per bypassare i rilevamenti basati su hook di ciclo vita npm. Vengono pubblicati 57 pacchetti malevoli attraverso oltre 286 versioni, con il trigger nascosto in file binding.gyp — un file di configurazione per la compilazione nativa che sfugge agli scanner focalizzati su preinstall e postinstall.
• 3 giugno 2026: il worm colpisce su due fronti simultaneamente. Lato npm, l'ondata binding.gyp prosegue; lato repository, Miasma salta completamente il registro npm e inietta direttamente file di configurazione malevoli in repository pubblici come icflorescu/mantine-datatable, prendendo di mira Claude Code, Gemini CLI e Cursor.
• 5 giugno 2026: il worm raggiunge Microsoft. Un account contributor precedentemente compromesso viene usato per pushare un commit malevolo nel repository Azure/durabletask. Da lì, Miasma si propaga ad altri 72 repository distribuiti su quattro organizzazioni Microsoft, sfruttando le pipeline CI/CD e i token OIDC di GitHub Actions.

Secondo l'analisi pubblicata da StepSecurity, il punto di svolta è stato il passaggio dal modello "esegui all'installazione del pacchetto" al modello "esegui all'apertura della cartella". È questo che ha reso Miasma un salto di qualità nella minaccia alla supply chain software.

Come funziona tecnicamente il worm Miasma

Miasma non è un singolo malware ma una famiglia di payload correlati che condividono tecniche di offuscamento, cifratura e propagazione. L'analisi pubblicata da Microsoft Security, StepSecurity, SafeDep e dalla Cloud Security Alliance consente di ricostruirne l'architettura in modo dettagliato.

Il payload npm: l'inganno del binding.gyp

La tecnica più innovativa dell'Ondata 2 sfrutta un file apparentemente innocuo: binding.gyp. In un progetto Node.js legittimo, questo file descrive come compilare moduli nativi tramite node-gyp. Miasma vi inserisce un payload di soli 100 byte che forza l'esecuzione di node index.js durante la fase di compilazione. Il file package.json del progetto infetto appare del tutto pulito: nessun hook preinstall o postinstall sospetto, solo comandi di build legittimi.

L'index.js richiamato è tutt'altro che innocuo: pesa tra 4,2 e 4,9 MB ed è composto da JavaScript altamente offuscato. Il primo strato di offuscamento usa un array di codici carattere ricostruito a runtime, decodificato tramite cifrario di Cesare (ROT-XX) ed eseguito dinamicamente con eval(). Il payload interno è cifrato in AES-128-GCM, con due blob separati e un loader che usa la funzione createDecipheriv di Node.js. I dati esfiltrati vengono cifrati con AES, la chiave viene wrappata con una chiave pubblica RSA incorporata e il bundle viene caricato su repository GitHub creati sotto l'account della vittima.

Il vettore AI agent: Claude Code, Gemini CLI e Cursor

L'innovazione più allarmante di Miasma è l'uso degli AI coding agent come canale di propagazione. Il worm non si limita a infettare il codice: infetta le istruzioni che governano gli assistenti AI degli sviluppatori. Il meccanismo sfrutta i file di configurazione specifici di ogni tool:

• Claude Code (.claude/settings.json): Miasma aggiunge un hook SessionStart che esegue automaticamente node .github/setup.js ogni volta che lo sviluppatore avvia una sessione di Claude Code nella cartella del repository.
• Gemini CLI (.gemini/settings.json): struttura identica a Claude Code. L'hook SessionStart si attiva all'avvio della sessione Gemini CLI.
• Cursor (.cursor/rules/setup.mdc): il worm sfrutta il sistema di regole Cursor con un file markdown che include il flag alwaysApply: true e l'istruzione di eseguire node .github/setup.js. L'AI agent di Cursor interpreta questa regola come un'istruzione legittima di progetto e la esegue.

Il punto cruciale è che non serve installare nulla. Basta clonare un repository infetto e aprirlo in uno di questi strumenti. Il file .github/setup.js, che può sembrare uno script di configurazione del repository, viene eseguito automaticamente dall'AI agent. Da lì, il worm ruba credenziali, token OAuth, cookie di sessione e chiavi SSH, e li usa per propagarsi in nuovi repository a cui la vittima ha accesso.

La propagazione orizzontale: CI/CD e OIDC

Miasma eccelle nel movimento laterale. Una volta ottenute credenziali valide, il worm:

1. Cerca token GitHub Actions e PAT (Personal Access Token) nell'ambiente della vittima.
2. Sfrutta l'OIDC Trusted Publishing — ironicamente, un meccanismo progettato proprio per eliminare i segreti a lunga vita — per pubblicare nuove versioni malevole di pacchetti npm.
3. Crea nuovi repository sotto l'account GitHub della vittima con nomi ispirati all'universo di Dune e la descrizione "Shai-Hulud: Here We Go Again" come marcatore della campagna.
4. Utilizza un canale C2 di backup che risolve dinamicamente endpoint cercando issue GitHub contenenti chiavi codificate.

Secondo l'analisi di StepSecurity, un ex dipendente Red Hat ha visto le proprie credenziali — inclusi cookie di sessione capaci di bypassare l'MFA — apparire nei log di infostealer già ad aprile 2026. Chi deteneva quelle credenziali a maggio, plausibilmente non le ha mai perse del tutto. È quella che Brad McCarty di StepSecurity ha definito "la stessa ferita che si riapre".

Perché gli AI agent sono il nuovo anello debole della supply chain

L'aspetto più dirompente di Miasma non è la tecnica di offuscamento — sofisticata ma non inedita — bensì il cambio di paradigma nell'attack surface. Per anni, la difesa della supply chain si è concentrata su due punti: il momento dell'installazione dei pacchetti (hook preinstall/postinstall, setup.py) e l'integrità del codice pubblicato (firme, checksum, attestazioni). Miasma aggira entrambi i livelli spostando l'esecuzione malevola su un terzo canale: l'editor di codice potenziato dall'AI.

I dati raccolti dall'Agent Security League di Endor Labs mostrano un quadro preoccupante. A marzo 2026, Cursor con Claude Opus 4.6 raggiungeva un tasso di completamento funzionale dell'84,4%, ma solo il 7,8% delle soluzioni generate era sicuro. Cursor con Gemini 3.1 Pro arrivava al 73,7% funzionale con appena il 13,4% di codice sicuro. Questi strumenti sono eccellenti nel rispondere a istruzioni, ma non hanno alcuna capacità intrinseca di distinguere un'istruzione legittima da una malevola — ed è esattamente questa la falla che Miasma sfrutta.

Per uno sviluppatore italiano, il rischio si amplifica in contesti dove l'adozione degli AI coding agent sta crescendo rapidamente senza un corrispondente adeguamento delle policy di sicurezza. In molte PMI, gli strumenti AI vengono adottati individualmente dai developer, senza passare attraverso valutazioni di sicurezza aziendali.

Guida pratica alla difesa: cinque azioni immediate

Le raccomandazioni che seguono sono basate sulle linee guida pubblicate da Cloud Security Alliance, StepSecurity, SafeDep e Microsoft Security all'indomani della campagna Miasma. Sono azioni concrete, verificabili e prioritarizzate.

1. Ispezionare i file di configurazione AI nei repository

Prima di aprire qualsiasi repository — proprio o clonato — in Claude Code, Gemini CLI, Cursor o Copilot, verificare la presenza di file sospetti. Miasma lascia tracce specifiche:

• File .claude/settings.json con hook SessionStart non previsti
• File .gemini/settings.json con struttura analoga
• File .cursor/rules/setup.mdc o qualsiasi .mdc con alwaysApply: true
• File .vscode/settings.json con comandi di esecuzione automatica
• Script .github/setup.js non documentato nel progetto

Il comando git diff prima di aprire il progetto in un AI agent dovrebbe diventare prassi standard. SafeDep consiglia di trattare qualsiasi file inaspettato nelle directory .claude/, .gemini/, .cursor/ e .vscode/ come potenzialmente malevolo fino a prova contraria.

2. Ruotare ogni credenziale potenzialmente compromessa

Se un'organizzazione ha consumato pacchetti @redhat-cloud-services in pipeline CI/CD o nei flussi di lavoro degli sviluppatori, deve considerare come potenzialmente compromessi: token di pubblicazione npm, GitHub Personal Access Token e OAuth token, credenziali cloud (AWS, Azure, GCP), cookie di sessione e chiavi SSH. La rotazione deve essere completa: Miasma è progettato per persistere e i cookie di sessione possono bypassare l'MFA.

3. Proteggere le GitHub Actions con controllo degli accessi di rete

La propagazione del worm attraverso le pipeline CI/CD è stata facilitata da runner GitHub Actions con accesso di rete illimitato. Lo strumento Harden-Runner di StepSecurity (open-source) applica controlli di egress di rete ai runner, bloccando la capacità del malware di esfiltrare dati o contattare endpoint C2. Per le pipeline esistenti, un audit con GitHub Actions Advisor aiuta a identificare configurazioni a rischio.

Altre misure immediate per GitHub Actions:

• Limitare i permessi dei token GITHUB_TOKEN allo stretto necessario (principio del minimo privilegio)
• Bloccare l'esecuzione di workflow da fork di repository pubblici senza revisione
• Impostare il flag persist-credentials: false nei checkout delle Actions quando non servono credenziali

4. Adottare scanner specifici per la supply chain

Gli strumenti tradizionali di sicurezza applicativa (SAST, DAST) non rilevano Miasma perché il codice malevolo non risiede nella logica applicativa ma nei file di configurazione dell'ambiente di sviluppo. Servono strumenti dedicati:

• Socket e SafeDep: scannerizzano i pacchetti npm alla ricerca di comportamenti sospetti come accessi al filesystem, rete e variabili d'ambiente, indipendentemente dagli hook di ciclo vita.
• StepSecurity Harden-Runner: aggiunge un layer di runtime security ai runner GitHub Actions.
• Chain-bench: scanner open-source per il benchmark CIS Software Supply Chain su GitHub e GitLab.
• Allstar: strumento open-source della OpenSSF per l'applicazione di policy di sicurezza su repository GitHub.
• JFrog Xray: offre rilevamento per pacchetti malevoli con analisi comportamentale.

Per le PMI italiane, Socket offre un piano gratuito che fornisce una copertura di base ed è integrabile direttamente su GitHub. StepSecurity Harden-Runner è open-source e installabile in pochi minuti sulle pipeline Actions esistenti.

5. Implementare il principio della