AsyncAPI compromessa su npm: Miasma colpisce pacchetti con 2,9 milioni di download

🛡️ Executive Summary

• Gli attaccanti ottengono accesso push ai repository AsyncAPI e sfruttano GitHub Actions per pubblicare cinque versioni npm malevole con provenance valida.
• Il dropper si attiva durante import o require, scarica Miasma da IPFS e sottrae credenziali cloud, GitHub, npm, Kubernetes e wallet.
• Chi ha caricato le versioni compromesse deve isolare i sistemi, cercare persistenza e ruotare immediatamente tutti i token potenzialmente esposti.

L’organizzazione AsyncAPI ha subito il 14 luglio 2026 un attacco supply chain che ha trasformato i propri workflow GitHub Actions in un canale legittimo per pubblicare su npm cinque pacchetti infetti. Gli aggressori non hanno sottratto direttamente un token npm: hanno ottenuto accesso push ai repository del progetto, modificato branch autorizzati e lasciato che le pipeline ufficiali firmassero e distribuissero il codice malevolo. Le versioni compromesse appartengono a pacchetti che totalizzano oltre 2,9 milioni di download settimanali, con @asyncapi/specs da solo sopra quota 2,7 milioni. Il payload finale è Miasma, framework RAT multi-stadio capace di rubare credenziali, installare persistenza su Windows, Linux e macOS e comunicare attraverso più canali resilienti.

I workflow ufficiali hanno pubblicato il malware con provenance valida

L’attacco è iniziato alle 06:58 UTC, quando un commit malevolo è stato inserito nel branch next del repository asyncapi/generator. Il messaggio, apparentemente innocuo, era “fix: test release workflow on next”, mentre l’autore riportava l’identità placeholder “Your Name” associata all’account invalid-email-address. Alle 07:10 il workflow release-with-changesets.yml ha pubblicato automaticamente tre versioni infette. Gli aggressori hanno poi modificato il branch master di spec-json-schemas, attivando if-nodejs-release.yml e distribuendo alle 08:06 una release alpha di @asyncapi/specs, seguita alle 08:30 dalla versione contrassegnata come latest. Tra le 11:12 e le 11:18 i maintainer hanno rimosso le release e ripristinato i tag sicuri. La gravità tecnica risiede nel fatto che i pacchetti disponevano di attestazioni SLSA e npm provenance formalmente corrette, perché erano stati prodotti da workflow autentici. La provenance certificava quale pipeline avesse generato l’artefatto, ma non poteva stabilire che il commit di partenza fosse stato inserito da un intruso. È lo stesso limite emerso in precedenti compromissioni delle GitHub Actions usate per attaccare progetti e catene di build: un workflow fidato non rende affidabile il codice se l’attaccante controlla il branch dal quale parte il rilascio.

Cinque pacchetti espongono una base installata potenzialmente enorme

Le versioni malevole comprendono @asyncapi/generator 3.3.1, @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1 e @asyncapi/specs nelle release 6.11.2-alpha.1 e 6.11.2. Le ultime versioni note come sicure erano rispettivamente 3.3.0, 1.1.0, 0.7.0 e 6.11.1. I volumi settimanali erano di circa 126.000 download per generator, 45.000 per generator-helpers, 46.000 per generator-components e oltre 2,74 milioni per specs. Il dato non significa che 2,9 milioni di sistemi siano stati necessariamente infettati durante le quattro ore dell’incidente, ma misura l’ampiezza dell’ecosistema che dipende da quei moduli. AsyncAPI viene utilizzato per descrivere, validare e generare documentazione o codice destinato ad architetture event-driven, broker di messaggistica e API asincrone.

I pacchetti possono quindi essere importati da pipeline CI/CD, strumenti di sviluppo e applicazioni enterprise senza essere eseguiti manualmente da un utente. L’incidente ricorda la compromissione di 140 pacchetti Mastra attribuita a Sapphire Sleet, ma presenta un elemento particolarmente insidioso: il malware è entrato attraverso repository ufficiali e release automatizzate, non mediante typosquatting o nomi imitativi.

Il dropper si attiva soltanto quando il modulo viene caricato

Il codice malevolo è stato inserito in validator.js, utils.js, ErrorHandling.js e index.js, a seconda del pacchetto coinvolto. Gli aggressori hanno nascosto le istruzioni attraverso nomi esadecimali, funzioni offuscate e centinaia di spazi aggiunti dopo le normali chiusure del codice, rendendo più difficile individuare la modifica durante una revisione superficiale. Il dropper non utilizza script npm come preinstall o postinstall, quindi non si attiva nel momento in cui il pacchetto viene semplicemente scaricato. L’esecuzione parte quando l’applicazione carica il modulo attraverso require o import. Questa scelta aggira numerosi controlli dedicati ai lifecycle hook e rende vulnerabili anche build che vietano gli script d’installazione.

Una volta eseguito, il codice usa child_process.spawn con processo detached e input-output ignorato per avviare una seconda istanza nascosta di Node.js. Il processo scarica da IPFS un file denominato sync.js, collocandolo in %LOCALAPPDATA%\NodeJS\ su Windows, /Library/Application Support/NodeJS/ su macOS e /.local/share/NodeJS/ su Linux. Il vettore conferma l’evoluzione già osservata con node-ipc trasformato in una backdoor capace di sottrarre credenziali cloud e chiavi SSH: i pacchetti di sviluppo sono un punto privilegiato perché vengono eseguiti su sistemi che custodiscono accessi ad ambienti produttivi.

Miasma raccoglie credenziali cloud, token e chiavi degli sviluppatori

sync.js funziona come loader cifrato e avvia il framework miasma-train-p1, composto da centinaia di moduli. Il componente HostCredentialSweeper cerca dati sensibili nei browser, chiavi SSH e GPG, configurazioni npm, token della GitHub CLI, credenziali AWS, Azure e Google Cloud, file kubeconfig, accessi Docker e Kubernetes, wallet crypto e configurazioni di strumenti AI come Claude, Gemini e Cursor. Miasma può inoltre eseguire comandi shell, leggere e modificare file, raccogliere informazioni sul sistema e aggiornare i propri moduli. L’obiettivo non consiste soltanto nel controllo della workstation: le credenziali sottratte possono permettere di compromettere ulteriori repository, registri di pacchetti, cluster, tenant cloud e pipeline di rilascio. Si crea così un meccanismo di propagazione nel quale ogni sviluppatore infetto può diventare il punto di ingresso per una nuova supply chain.

La capacità era già stata documentata quando Miasma aveva compromesso 32 pacchetti npm collegati all’ecosistema Red Hat e successivamente quando il malware aveva colpito sviluppatori attraverso finti inviti OpenAI e repository apparentemente legittimi.

Persistenza e sei canali C2 rendono difficile la rimozione

Il RAT crea servizi systemd su Linux, attività o voci di avvio su Windows e agenti launchd su macOS. Un motore di mutazione modifica le copie distribuite per ridurre l’efficacia delle firme statiche. Il comando e controllo utilizza sei meccanismi con failover: HTTP diretto verso 85.137.53.71 sulle porte 8080 e 8081, relay Nostr, smart contract Ethereum, IPFS, rete BitTorrent DHT e libp2p. Se il server principale viene bloccato, il malware può recuperare istruzioni attraverso infrastrutture decentralizzate più difficili da sequestrare. I contenuti vengono protetti con AES-256-GCM e chiavi derivate tramite HKDF-SHA256. Il framework comprende anche proxy, discovery mDNS e funzioni che possono facilitare il movimento laterale nella rete locale. Alcuni moduli destinati alla propagazione verso ulteriori ecosistemi erano presenti ma non attivati nella configurazione osservata. Questa struttura modulare rende Miasma più simile a una piattaforma criminale che a un semplice infostealer e spiega perché il malware sia stato più volte associato ad attacchi contro GitHub, npm e PyPI, compresa la campagna che ha distribuito 37 wheel Python malevoli con uno stealer basato su Bun.

La rimozione da npm non neutralizza i sistemi già compromessi

Le organizzazioni devono verificare lockfile, cache dei package manager, artefatti di build, immagini container e log CI/CD per stabilire se una delle versioni malevole sia stata installata e successivamente caricata tra le 07:10 e le 11:18 UTC del 14 luglio. La sola presenza nel lockfile non prova l’esecuzione, ma richiede di controllare se test, generatori o applicazioni abbiano importato il modulo. Gli indicatori principali comprendono processi Node.js detached, file sync.js nelle directory nascoste, servizi systemd o launchd insoliti, nuove persistenze Windows e connessioni verso 85.137.53.71. Un sistema che ha eseguito il codice deve essere isolato e trattato come compromesso. È necessario ruotare token npm e GitHub, chiavi SSH, credenziali cloud, accessi Kubernetes e Docker, segreti CI/CD e token degli strumenti AI. La rotazione deve avvenire da un dispositivo pulito e includere la revoca delle sessioni già emesse. Le aziende devono inoltre rigenerare artefatti e immagini prodotte durante la finestra di compromissione, perché il payload potrebbe essere stato incorporato in build successive anche dopo la rimozione delle release.

AsyncAPI dimostra il limite dei controlli centrati soltanto sulla pubblicazione

L’incidente mostra che token npm a scadenza breve, autenticazione forte e provenance non bastano quando l’avversario può modificare il codice sorgente autorizzato. I progetti devono proteggere i branch di rilascio con review obbligatorie, firme dei commit, regole che impediscano push diretti, separazione dei ruoli e approvazione manuale per la pubblicazione di versioni stabili. I workflow dovrebbero verificare la corrispondenza tra commit approvato, tag e contenuto dell’artefatto, evitando che una semplice modifica al branch attivi automaticamente il rilascio latest. Npm sta introducendo strumenti come lo staged publishing per limitare gli effetti delle compromissioni della supply chain, ma la protezione deve estendersi a GitHub, identità dei maintainer e dipendenze eseguite in CI. AsyncAPI conferma che un pacchetto può avere editore corretto, workflow corretto e attestazione corretta, pur distribuendo malware: la catena di fiducia è valida soltanto quanto il punto più debole che autorizza la modifica del codice.