Il 14 luglio 2026 un attaccante ha compromesso la pipeline di rilascio di AsyncAPI. Cinque versioni malevole di quattro pacchetti npm, con oltre due milioni di download settimanali, sono state distribuite con attestazioni di provenance SLSA valide: la firma digitale che doveva garantire l'autenticità è diventata il velo che ha reso il malware indistinguibile dal software legittimo.
L'operazione ha sfruttato una vulnerabilità nota da mesi in un workflow GitHub Actions. Il payload, identificato come framework M-RED-TEAM v6.4, esegue a import-time — non a install-time — rendendo inutile la mitigazione standard --ignore-scripts che npm ha promosso come difesa.
- L'attacco è iniziato il 14 luglio 2026 alle 05:08 UTC con una pull request malevola nel repository asyncapi/generator, sfruttando un workflow GitHub Actions configurato con
pull_request_targetche eseguiva checkout di codice non attendibile con accesso ai secrets del repository base. - Cinque versioni malevole — @asyncapi/generator 3.3.1, generator-helpers 1.1.1, generator-components 0.7.1, specs 6.11.2-alpha.1 e specs 6.11.2 stabile — sono state pubblicate tra le 07:10 e le 08:30 UTC, tutte con provenance SLSA valida generata tramite GitHub OIDC trusted publishing.
- Il payload opera in tre stadi: un downloader offuscato di circa 3 KB nei file main/index.js dei pacchetti, un bundle di circa 8,2 MB cifrato con AES-256-GCM scaricato da IPFS, e il framework M-RED-TEAM v6.4 di circa 92.000 linee con architettura modulare.
- La comunicazione con il server di comando e controllo si appoggia su una rete multi-canale: HTTP verso l'indirizzo 85.137.53.71, IPFS, relay Nostr, smart contract Ethereum all'indirizzo 0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710, libp2p e bootstrap nodes BitTorrent DHT.
La trappola del pull_request_target
Il vettore d'ingresso era documentato da mesi. Il 29 aprile 2026 era già stata identificata la vulnerabilità nel workflow manual-netlify-preview.yml, con una proof-of-concept e una patch proposta il 17 maggio che non era stata mai integrata. L'attaccante ha aperto 37 pull request: 36 decoy con riferimenti falsi a enti di beneficenza, e la PR #2155 con il payload effettivo.
La configurazione con pull_request_target ha permesso l'esecuzione del workflow nel contesto del repository base, dove i secrets erano accessibili. Il codice JavaScript offuscato iniettato nella pull request puntava a esfiltrare un personal access token dell'account asyncapi-bot verso rentry[.]co/elzotebo999. Secondo Microsoft Threat Intelligence, i log del workflow non mostrano esplicitamente il successo della richiesta web; il meccanismo esatto di acquisizione del token non è confermato dai dati disponibili.
Con il token in mano — o con altro meccanismo non verificato — l'attaccante ha effettuato push di commit sotto un'identità git segnaposto, lasciando che i workflow di rilascio automatico — legittimi e non modificati — pubblicassero i pacchetti su npm tramite l'integrazione OIDC trusted-publisher. Come ha documentato StepSecurity: "Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers". Le attestazioni di provenance Sigstore/Fulcio risultanti erano tecnicamente autentiche: riportavano il repository corretto, il workflow corretto, gli SHA dei commit.
Il bypass dell'import-time
La vera caratteristica tattica sta nel momento di attivazione. Il codice malevolo è inserito nei file main/index.js dei pacchetti compromessi: viene eseguito nel momento in cui un'applicazione fa require() o import, non durante la fase di installazione gestita da npm install. Questo annulla la protezione offerta da --ignore-scripts, la flag con cui npm ha provato a mitigare gli attacchi supply chain limitando l'esecuzione degli hook del ciclo di vita.
"npm's v12 is out, blocking post-install scripts, but threat actors didn't need to use them as they just embedded the malicious code inside the main JavaScript file without being blocked" — OX Security report, citato da Security Affairs
Il payload di primo stadio è minuscolo, circa 3 KB, con tecniche di offuscamento e padding a whitespace per evitare rilevamenti basati sulla dimensione. Attiva il download del secondo stadio, un file sync.js di circa 8,2 MB ospitato su IPFS e cifrato con AES-256-GCM con derivazione chiave HKDF-SHA256. La decrittazione e l'esecuzione caricano il terzo stadio: il framework M-RED-TEAM v6.4, che si auto-identifica esplicitamente nei commenti del codice secondo l'analisi di Wiz Research.
C2 decentralizzato e persistenza cross-platform
L'infrastruttura di comando e controllo è progettata per resistere ai takedown convenzionali. Il canale primario è un server HTTP all'indirizzo 85.137.53.71 sulle porte 8080, 8081 e 8091. I fallback sfruttano reti peer-to-peer e decentralizzate: contenuti IPFS indirizzabili tramite CID specifici, relay del protocollo Nostr, smart contract Ethereum per la distribuzione di configurazioni o indirizzi, e bootstrap nodes della DHT BitTorrent connessi via libp2p.
Il payload implementa meccanismi di persistenza su tutte e tre le piattaforme principali: un servizio systemd user-level denominato miasma-monitor.service su Linux, una chiave nel registro HKCU Run su Windows, e modifiche ai file .zshrc e .bashrc su macOS. L'analisi di Aikido evidenzia un limite implementativo: il servizio systemd manca di un wrapper shell nell'istruzione ExecStart, con conseguente probabile fallimento dell'avvio automatico. Per le altre due piattaforme, il brief non verifica il funzionamento effettivo dei meccanismi di persistenza.
Il payload contiene riferimenti a funzionalità di credential harvesting e self-propagation verso npm, PyPI e Cargo, ma l'analisi di Aikido conferma che queste capacità erano disabilitate in questa build. Rimane attiva una shell remota che permette esecuzione manuale. Il payload include inoltre controlli anti-VM, anti-EDR e anti-Russia: termina se rileva una locale russa.
Cosa fare adesso
La finestra di esposizione è stata di circa 4 ore e 7 minuti, dalle 07:10 alle 11:18 UTC del 14 luglio 2026. Durante questo intervallo i pacchetti malevoli erano disponibili sul registry npm prima della rimozione. Microsoft Threat Intelligence ha pubblicato indicatori di compromissione e query di rilevamento per Microsoft Defender.
I pacchetti compromessi sono: @asyncapi/generator 3.3.1, generator-helpers 1.1.1, generator-components 0.7.1, specs 6.11.2-alpha.1 e specs 6.11.2. Le versioni precedenti non sono interessate. Wiz ha rilevato l'attacco tramite monitoring automatico entro 30 minuti dalla pubblicazione. StepSecurity ha eseguito analisi runtime indipendente con Harden-Runner confermando il comportamento C2 e ha bloccato gli IOC nella propria Global Block List.
Secondo l'analisi di DeafNews, il passaggio da C2 centralizzati a infrastrutture distribuite basate su IPFS, Nostr e blockchain rappresenta per questo specifico incidente una complessità tattica superiore rispetto agli attacchi supply chain tradizionali. La capacità di distribuire payload con provenance SLSA valida attraverso workflow legittimi compromessi — piuttosto che tramite furto di token o impersonazione di maintainer — indica che il punto di attacco si è spostato verso l'integrità del processo di build stesso.
La prossima generazione di difese, secondo l'analisi di DeafNews, dovrà affrontare la verifica non solo della firma, ma dell'integrità del processo che la genera: un repository compromesso produce attestazioni tecnicamente valide ma semanticamente traditrici.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://securityaffairs.com/195395/security/asyncapi-npm-supply-chain-attack-malware-injected-into-packages-with-2-million-weekly-downloads.html
- https://www.bleepingcomputer.com/news/security/-asyncapi-npm-packages-infected-with-credential-stealing-malware/
- https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/
- https://www.wiz.io/blog/m-red-team-asyncapi-supply-chain-compromise-via-github-actions
- https://www.aikido.dev/blog/asyncapi-npm-packages-backdoored-via-github-actions
- http://www.stepsecurity.io/blog/compromised-next-branch-pushes-malicious-asyncapi-generator-generator-helpers-and-generator-components-to-npm
- https://securityaffairs.com/195395/security/asyncapi-npm-supply-chain-attack-malware-injected-into-packages-with-2-million-weekly-downloads.html/attachment/image-1529
- https://resecurity.com/