Una campagna di attacco alla supply chain ha compromesso 73 repository Microsoft su GitHub, colpendo organizzazioni di alto profilo come Azure, Azure-Samples, Microsoft e MicrosoftDocs. Il responsabile è un worm auto-replicante denominato Miasma, variante del malware Mini Shai-Hulud rilasciato pubblicamente dal gruppo TeamPCP a metà maggio 2026.
L’incidente ha costretto GitHub a disabilitare l’accesso ai repository compromessi, tra cui alcuni di assoluta centralità nell’ecosistema Microsoft open source, come Azure/azure-functions-host e l’intera famiglia dei Durable Task SDK.
La catena di compromissione: dai pacchetti PyPI ai repository GitHub
Miasma non è una minaccia nuova: il worm ha già colpito in precedenza. Il mese prima di questo incidente, il pacchetto PyPI durabletask era stato infettato da TeamPCP per consegnare un information stealer su sistemi Linux. Il fatto che, un mese dopo, l’intero ecosistema Durable Task su GitHub sia stato compromesso — incluse le implementazioni .NET, Go, Java, JavaScript, MSSQL e Protobuf — non è una coincidenza.
Come ha osservato il ricercatore di sicurezza Paul McCarty (alias 6mile): “Quando il repository al centro dell’attacco del mese scorso diventa l’epicentro del takedown di questo mese, non è una coincidenza — è la stessa ferita che si riapre. Chi deteneva quelle credenziali a maggio non le ha probabilmente mai perso del tutto.”
Come funziona Miasma: sfruttare la fiducia, non le vulnerabilità
Quello che rende Miasma particolarmente pericoloso è il suo meccanismo di propagazione: il worm non sfrutta vulnerabilità tecniche nei registri npm o in GitHub. Sfrutta invece il modello di fiducia su cui si reggono questi ecosistemi.
Come sintetizza FalconFeeds.io: “Il genio del worm sta nel fatto che opera interamente attraverso canali legittimi. Non sfrutta una vulnerabilità in npm o GitHub. Sfrutta il modello di fiducia su cui queste piattaforme sono costruite: l’assunzione che se un pacchetto è firmato con una chiave valida e pubblicato da un maintainer autenticato, sia sicuro. Miasma compromette la chiave e il maintainer, poi agisce esattamente come farebbe un publisher legittimo.”
Da un punto di vista dei sistemi di difesa convenzionali, ogni evento di pubblicazione malevolo è indistinguibile da un aggiornamento ordinario.
Il vettore di attacco: gli agenti AI come trigger
Uno degli aspetti più innovativi — e preoccupanti — di Miasma è il suo vettore di detonazione. Secondo l’analisi di SafeDep, il worm ha piantato un payload runner da 4,3 MB nei repository infetti, configurato per attivarsi automaticamente attraverso cinque strumenti di sviluppo:
In pratica: uno sviluppatore clona un repository infetto, lo apre nel suo agente AI preferito, e il payload si esegue automaticamente. Nessun click, nessuna interazione esplicita richiesta.
Questo segna un’evoluzione significativa nel panorama degli attacchi supply chain: gli agenti AI, progettati per eseguire codice in autonomia, diventano inconsapevolmente vettori di esecuzione per payload malevoli.
I repository Microsoft colpiti
Tra i repository compromessi e disabilitati da GitHub figurano:
Azure/azure-functions-hostAzure/durabletaskdurabletask-dotnetdurabletask-godurabletask-jsdurabletask-mssqlazure-search-openai-demo-purviewdatasecurityllm-fine-tuningwindows-driver-docsConnectors-NET-SDK,Connectors-NET-LSP
Oltre ai repository Microsoft, Miasma ha saltato completamente il registro npm in alcuni casi, compromettendo direttamente il repository GitHub icflorescu/mantine-datatable e quattro repository correlati (mantine-contextmenu, next-server-actions-parallel, mantine-datatable-v6, mantine-contextmenu-v6).
Come difendersi dagli attacchi supply chain di questa generazione
La natura di Miasma — operare all’interno dei canali legittimi — rende i controlli tradizionali insufficienti. Ecco le misure pratiche che i team di sviluppo e i sistemisti dovrebbero adottare:
1. Lockfile e hash verification
Usare sempre lockfile (package-lock.json, poetry.lock, go.sum) e verificare gli hash dei pacchetti. Non fare mai npm install o pip install senza version pinning stretto su ambienti di produzione e CI.
2. Controllo delle permission degli agenti AI
Configurare gli agenti AI (VS Code, Cursor, Claude Code, Gemini CLI) in modo che non eseguano script automaticamente alla clonazione di un repository. Molti agenti hanno modalità di esecuzione permissiva abilitata di default: è necessario revisionare le impostazioni.
3. Ambienti sandbox per il codice sconosciuto
Prima di aprire repository esterni in un agente AI, eseguire un’ispezione manuale dei file package.json, pyproject.toml, script di lifecycle, e configurazioni degli agenti (.cursor/, .claude/, .vscode/). Meglio ancora: usare ambienti sandbox isolati (container, VM) per il primo accesso a codice di terze parti.
4. Monitoraggio delle dipendenze con tool come OpenSourceMalware e SafeDep
Strumenti come OpenSourceMalware e SafeDep monitorano attivamente l’ecosistema npm, PyPI e GitHub per rilevare comportamenti anomali nei pacchetti. Integrare questi feed nei processi di revisione delle dipendenze.
5. Principio del minimo privilegio per le credenziali di repository
La ricompaprsa delle stesse credenziali a distanza di un mese dimostra che il reset delle credenziali post-incidente spesso non è completo. Implementare credenziali rotate automaticamente, short-lived token (es. GitHub OIDC token in CI), e auditing degli accessi ai repository.
Il quadro più ampio: la minaccia ai modelli di sviluppo moderni
L’attacco Miasma evidenzia una tensione strutturale nell’ecosistema software moderno: la velocità e l’apertura che rendono l’open source produttivo sono le stesse caratteristiche che lo rendono vulnerabile a questa classe di attacchi. I worm supply chain che operano “dentro le regole” sono una categoria di minaccia che crescerà, soprattutto con la diffusione degli agenti AI come strumenti di sviluppo quotidiani.
Per i team di sviluppo e i sistemisti, il messaggio è chiaro: i controlli di sicurezza devono evolvere oltre la verifica dell’autenticità formale dei pacchetti, verso un’analisi comportamentale dei contenuti e una gestione più granulare delle permission degli strumenti di sviluppo.
Fonte: 4sysops – Miasma worm compromises 73 Microsoft GitHub repositories | The Hacker News – Miasma Worm Hits 73 Microsoft GitHub Repositories