Il worm Miasma colpisce Microsoft: quando il malware si esegue aprendo il repository nell’IDE con l’AI

Lo stesso worm di supply chain che a inizio mese ha colpito i pacchetti npm di Red Hat, il worm Miasma, ha aperto un capitolo nuovo e più insidioso: Microsoft ha confermato lunedì 8 giugno di aver rimosso temporaneamente decine di propri repository open source su GitHub dopo che la campagna ne ha compromessi 73, iniettando un information stealer nel codice. La conferma, arrivata mentre l’indagine è ancora in corso, sposta l’attenzione su una mutazione tecnica che cambia le regole del gioco per la sicurezza della catena di fornitura del software: il payload non si attiva più all’installazione del pacchetto, ma nel momento in cui uno sviluppatore apre la cartella del progetto nel proprio editor o in un agente di coding basato su intelligenza artificiale.

Che cosa è successo

Il 5 giugno un commit malevolo (identificativo 5f456b8) è stato spinto direttamente nel repository Azure/durabletask usando l’account di un contributor già compromesso. Il messaggio del commit dichiarava una modifica al codice, ma nessun file sorgente è stato toccato: i cinque file aggiunti erano tutti file di configurazione o il payload stesso. Il commit era retrodatato al 2020 e marcato con il flag [skip ci] per sopprimere la pipeline di verifica automatica ed eludere il rilevamento.

Poche ore dopo, il sistema antiabuso di GitHub ha disabilitato 73 repository distribuiti su quattro organizzazioni Microsoft (Azure, microsoft, Azure-Samples e MicrosoftDocs) in una raffica automatizzata di 105 secondi, tra le 16:00:50 e le 16:02:35 UTC. La firma di sicurezza StepSecurity, che ha ricostruito l’incidente, ha verificato ogni repository tramite le API di GitHub: tutti restituivano un errore 403 per violazione dei termini di servizio, e l’azione risultava chirurgicamente mirata a quei 73 progetti e non a un perimetro più ampio.

Qui emerge uno scarto narrativo che vale la pena segnalare. La comunicazione ufficiale parla di repository «rimossi temporaneamente» da Microsoft; l’evidenza forense, l’errore 403 con motivazione «tos» e la raffica automatizzata, descrive invece un’azione di enforcement di GitHub, non un intervento manuale dell’azienda. La distanza tra «lo ha rimosso Microsoft» e «lo ha disabilitato l’automazione di GitHub» è un piccolo ma reale nodo di responsabilità.

Il salto di paradigma: esecuzione all’apertura, non all’installazione

Il dettaglio che rende la vicenda rilevante per chi difende le organizzazioni è il vettore. I cinque file piantati nel repository puntavano tutti allo stesso payload, un singolo file JavaScript offuscato da 4,6 MB ( .github/setup.js ), e attivavano l’esecuzione automatica su quattro strumenti diversi: un hook SessionStart in .claude/settings.json per Claude Code, l’analogo in .gemini/settings.json per Gemini CLI, una prompt injection in .cursor/rules/setup.mdc che istruisce l’agente di Cursor a lanciare il payload spacciandolo per inizializzazione del progetto, e un task folderOpen in .vscode/tasks.json per Visual Studio Code.

Clonare il repository è sicuro; aprirlo non lo è. Le difese della supply chain si sono storicamente concentrate sugli hook di installazione dei pacchetti ( preinstall , postinstall , setup.py ); qui l’attacco salta del tutto il gestore dei pacchetti e prende di mira l’editor dello sviluppatore. Un file .claude/settings.json con un hook di avvio sessione è, di fatto, un postinstall per il vostro editor. Una volta in esecuzione, il malware raccoglie credenziali ad alto valore (token GitHub e npm, chiavi AWS, service principal Azure, account di servizio GCP, segreti Kubernetes) e le esfiltra verso repository GitHub pubblici usati come dead drop.

L’effetto domino sulla CI/CD

La conseguenza più immediata è stata la disabilitazione di Azure/functions-action , l’azione ufficiale per il deploy delle Azure Functions. Ogni workflow che referenziava Azure/functions-action@v1 ha smesso di risolversi all’istante, e nel giro di poche ore un thread di supporto su Microsoft Learn raccoglieva oltre venti sviluppatori con le pipeline interrotte. Nelle prime ore Microsoft ha descritto il caso come «internal management issue» sotto indagine, salvo poi convergere sulla formula PR del «rimosso temporaneamente»: proprio qui si tocca con mano il nodo di responsabilità tra azienda e piattaforma. È poi il problema dei tag mutabili: quando il repository sparisce, il tag @v1 evapora e ogni workflow dipendente fallisce. Un riferimento bloccato a uno specifico commit SHA avrebbe fallito in modo prevedibile, senza propagare il guasto a valle.

Il quadro più ampio

L’incidente Microsoft non è isolato. L’account compromesso è lo stesso usato il 19 maggio per caricare tre versioni malevole del pacchetto durabletask su PyPI, e l’infrastruttura si ricollega alla più vasta campagna del worm Miasma, che ha infettato oltre 113 repository su decine di account ed è attribuita al gruppo TeamPCP, già responsabile di attacchi contro gli ecosistemi npm di TanStack, @antv e @redhat-cloud-services. L’8 giugno i ricercatori di StepSecurity hanno documentato una nuova ondata su PyPI, la campagna Hades, incentrata su librerie di graph machine learning e bioinformatica ( ensmallen , embiggen e affini), con payload capaci persino di depistare gli scanner assistiti da AI tramite una prompt injection nascosta nel bundle. A questa stessa famiglia si lega un cluster adiacente e più recente, segnalato da Socket, di pacchetti a tema Model Context Protocol ( langchain-core-mcp , openai-mcp , tiktoken-mcp ): va ricondotto all’ombrello più ampio Mini Shai-Hulud, Miasma e Hades, più che al nucleo originario della campagna.

Microsoft, da parte sua, ha dichiarato di aver ripristinato alcuni repository dopo la revisione, di mantenerne altri offline mentre l’indagine prosegue e di aver notificato un numero ristretto di clienti che potrebbero aver scaricato contenuti dai progetti interessati.

Perché conta

Per i responsabili della sicurezza il messaggio operativo è netto: i file di configurazione degli agenti di coding ( .claude/ , .gemini/ , .cursor/ , .vscode/tasks.json ) vanno trattati come segnali di supply chain, non come rumore dell’editor. Chi ha clonato e aperto uno dei repository interessati dopo il 2 giugno dovrebbe considerare la macchina compromessa e ruotare ogni credenziale accessibile da quel sistema. Sul piano preventivo restano centrali le regole di branch protection con revisione obbligatoria, il pinning delle azioni GitHub a commit SHA anziché a tag mutabili, la pubblicazione su PyPI tramite Trusted Publishing (OIDC) e la restrizione del traffico in uscita dai runner di CI/CD.