// 1 CRITICAL · 3 ZERO-DAY · 3 CVE · 3 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Il worm Miasma ha compromesso 73 repository Microsoft su GitHub. Il malware si attiva all'apertura in IDE o agenti AI, non all'installazione, bypassando le difese

Il 5 giugno 2026 un commit malevolo ha infettato il repository Azure/durabletask su GitHub, dando il via a una compromissione che in 105 secondi ha coinvolto 73 repository distribuiti su quattro organizzazioni Microsoft. Il worm Miasma non attacca i gestori di pacchetti né sfrutta vulnerabilità tecniche: si attiva quando uno sviluppatore apre il repository in un IDE o in un agente AI coding, trasformando strumenti di produttività in vettori di esecuzione automatica.

Punti chiave
  • 73 repository Microsoft su quattro organizzazioni (Azure, microsoft, Azure-Samples, MicrosoftDocs) sono stati compromessi dal worm Miasma
  • Il payload da 4,6 MB si attiva su Claude Code, Gemini CLI, Cursor e VS Code tramite file di configurazione dell'editor, non al clone o all'installazione del pacchetto
  • GitHub ha disabilitato i repository in 105 secondi (16:00:50-16:02:35 UTC), ma l'interruzione ha bloccato pipeline CI/CD dipendenti dall'azione ufficiale Azure/functions-action@v1
  • L'account contributor compromesso era già stato usato il 19 maggio per iniettare versioni malevole del pacchetto durabletask su PyPI, indicando un accesso persistente non interrotto

Il vettore postinstall dell'editor: da setup.py a .cursor/rules

Gli attacchi supply chain tradizionali puntano ai hook di installazione: preinstall, postinstall, setup.py. Il worm Miasma capovolge questa logica. Secondo la ricostruzione di StepSecurity, citata da ICT Security Magazine, il commit malevolo 5f456b8 aggiunge cinque file — tutti di configurazione o payload, nessun sorgente modificato — che si attivano all'apertura della cartella progetto nell'editor.

I quattro vettori documentati sono precisi. Claude Code esegue il payload tramite l'hook SessionStart in .claude/settings.json. Gemini CLI usa un meccanismo analogo in .gemini/settings.json. Cursor carica il codice tramite prompt injection in .cursor/rules/setup.mdc. Visual Studio Code attiva il task folderOpen da .vscode/tasks.json. Ognuno di questi file è legittimo per definizione: sono gli stessi che gli sviluppatori usano per automatizzare workflow locali.

"Instead of poisoning a package registry, the commit planted configuration files that trigger automatic code execution when a developer opens the repository in an AI coding tool or IDE" — Ashish Kurmi, StepSecurity (via The Hacker News)

La distinzione è netta: clonare il repository è sicuro, aprirlo nell'editor o nell'agente AI lo è molto meno. Questa separazione invalida un assunto radicato nella pratica degli sviluppatori e nelle architetture di difesa.

Come il bypass di SLSA è strutturale, non tecnico

Le firme SLSA, la provenance attestata e le scansioni dei gestori di pacchetto sono inutili qui. Il commit malevolo proviene da un account maintainer legittimo, compromesso ma tecnicamente autentico. Il payload non altera il build system né inietta dipendenze: modifica solo i file di configurazione dell'ambiente di sviluppo, al di fuori del perimetro che gli strumenti di supply chain security monitorano.

Il commit 5f456b8 era retrodatato al 2020 e marcato con il flag [skip ci], che ha soppresso la pipeline di verifica automatica di GitHub Actions. Questa combinazione — data falsa e silenziamento CI — ha ridotto la superficie di rilevamento senza violare alcun controllo di integrità. Il trust model della piattaforma è stato esercitato correttamente: un maintainer con credenziali valide ha spinto codice valido, solo che il codice era malevolo.

La questione non è quale strumento abbia fallito, ma quale strumento fosse deputato a guardare. Nessuno lo era.

Timeline della compromissione e risposta automatica di GitHub

Gli orari sono precisi. Il commit è stato spinto il 5 giugno 2026. Tra le 16:00:50 e le 16:02:35 UTC, il sistema antiabuso di GitHub ha disabilitato 73 repository in una raffica automatizzata. StepSecurity ha verificato via API che tutti restituivano errore 403 per violazione dei termini di servizio.

Microsoft ha dichiarato di aver "temporarily removed some repositories as we investigate potential malicious content", ma l'evidenza forense indica un enforcement automatico della piattaforma, non una rimozione manuale. L'interruzione ha avuto effetti a valle: l'azione ufficiale Azure/functions-action@v1 è stata disabilitata, interrompendo workflow CI/CD che ne dipendevano. Più di venti sviluppatori hanno segnalato interruzioni su thread Microsoft Learn.

L'account compromesso è lo stesso usato il 19 maggio per caricare versioni malevoli del pacchetto durabletask su PyPI, con oltre 417.000 download mensili. Secondo OpenSourceMalware, citato da Security Affairs: "When the repo at the root of last month's compromise is the hub of this month's takedown, that is not a coincidence — that is the same wound reopening". La continuazione suggerisce che le credenziali non siano state rototate completamente dopo il primo incidente, sebbene il dossier non specifichi se Microsoft abbia eseguito una rotazione parziale o nulla.

L'attore e il payload: raccolta ed esfiltrazione via GitHub stesso

Miasma è attribuito al gruppo TeamPCP, già responsabile di attacchi npm contro TanStack, @antv e @redhat-cloud-services. Il payload è un singolo file JavaScript offuscato da 4,6 MB (.github/setup.js), che raccoglie credenziali ad alto valore: token GitHub e npm, chiavi AWS, service principal Azure, account GCP, segreti Kubernetes.

L'esfiltrazione avviene verso repository GitHub pubblici usati come dead drop. La piattaforma diventa così infrastruttura C2: i dati rubati transitano attraverso canali legittimi, indistinguibili dal traffico ordinario. ICT Security Magazine riporta descrizioni evocative dei repository dead drop come "Miasma: The Spreading Blight" e "Hades: The End for the Damned", sebbene il dossier non specifichi se questi nomi siano stati osservati nel caso Microsoft o nella campagna più ampia.

Cosa fare adesso

Le fonti convergenti indicano quattro aree prioritarie per le organizzazioni che gestiscono repository o dipendono da action GitHub.

Trattare i file di configurazione AI/IDE come artefatti di sicurezza. I file .claude/settings.json, .cursor/rules/, .vscode/tasks.json e analoghi devono essere inclusi nelle scansioni pre-commit e nei controlli di code review, non considerati rumore dell'editor.

Verificare le dipendenze da action GitHub disabilitate. Le pipeline che usano Azure/functions-action@v1 o altre action nei repository colpiti devono essere riesaminate per interruzioni e per eventuale esposizione ai file di configurazione malevoli.

Isolare l'apertura di repository esterni. Aprire repository clonati in sandbox o container senza accesso a credenziali cloud, disabilitando l'esecuzione automatica di task e hook fino a verifica manuale.

Auditare gli account maintainer con accesso storico a PyPI e GitHub. Il pattern di re-compromissione — stesso account, stesso progetto, piattaforme diverse — indica che la rotazione delle credenziali dopo incidenti precedenti va verificata con attenzione particolare.

Perché questo attacco ridefinisce il perimetro

La novità di Miasma non è nel payload tecnicamente sofisticato: è nella ridefinizione del confine tra sicuro e pericoloso. Per decenni, l'installazione del software è stata la linea di demarcazione. Clonare, scaricare, aprire in sola lettura era considerato neutrale. Il worm Miasma sposta il pericolo all'apertura, nel momento in cui l'agente AI o l'IDE costruiscono il contesto del progetto.

Questo ha conseguenze per l'intero settore. I framework di provenance come SLSA sono progettati per garantire che il codice buildato corrisponda al codice sorgente verificato. Ma quando il codice sorgente stesso contiene istruzioni che si auto-eseguono al caricamento, la provenance diventa irrilevante: il codice è autentico, il maintainer è autentico, l'esecuzione è legittima, il risultato è catastrofico.

Gli agenti AI coding — Claude, Gemini, Cursor — sono promossi come acceleratori di produttività e, implicitamente, di sicurezza: meno codice scritto manualmente, meno errori. Il caso Miasma mostra il rovescio. L'automazione che rende l'apertura del repository frictionless rende anche l'esecuzione del malware invisibile. L'assistente che dovrebbe aiutare a scrivere codice sicuro diventa il vettore che esegue codice malevolo senza chiedere permesso.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. ictsecuritymagazine.com
  2. thehackernews.com
  3. securityaffairs.com
  4. defend.network
  5. nvd.nist.gov
  6. krebsonsecurity.com
  7. bleepingcomputer.com
  8. securityweek.com