AsyncAPI: cinque pacchetti npm compromessi con provenance valida

Il 14 luglio 2026 attaccanti hanno compromesso le pipeline CI/CD del progetto open source AsyncAPI, rubando il token del service account asyncapi-bot e pubblicando cinque versioni malevole di pacchetti npm con provenance attestations tecnicamente valide. Il payload Miasma si attiva al momento dell'import del modulo, non durante l'installazione, rendendo inefficace la mitigazione standard --ignore-scripts. L'incidente espone un paradosso strutturale della supply chain moderna: quando il repository sorgente cede, la firma di build diventa garanzia di codice compromesso.

Come si è aperto il varco: il pwn request in GitHub Actions

Gli attaccanti hanno aperto 37 pull request al repository asyncapi/generator nel corso del 14 luglio 2026. Una sola, la PR #2155, ha exploitato un workflow docs-preview configurato con pull_request_target, secondo Wiz Research. Questa modalità esegue il workflow nel contesto del repository base, con accesso completo ai segreti, ma il checkout del codice della PR ha introdotto codice controllato dall'attaccante nell'ambiente privilegiato.

Il workflow è stato completato alle 05:16 UTC e il token è stato esfiltrato. Alle 06:58 UTC il commit malevolo 3eab3ec è stato pushato direttamente sul branch next, scatenando il workflow di release alle 07:10 UTC. La finestra tra identificazione della vulnerabilità e exploit è durata 58 giorni: la segnalazione responsabile con proof-of-concept era arrivata il 29 aprile, la proposta di fix il 17 maggio, entrambe non mergate.

"Questo è pericoloso perché pull_request_target esegue nel contesto del repository base con accesso completo ai segreti. Quando il workflow effettua il checkout di codice controllato dall'attaccante dalla pull request e lo esegue, quei segreti diventano accessibili." — Wiz Research

Il payload Miasma: import-time execution e evasione dei controlli standard

Le cinque versioni compromesse — @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, @asyncapi/generator-helpers@1.1.1 (07:10 UTC), @asyncapi/specs@6.11.2-alpha.1 (08:06 UTC) e @asyncapi/specs@6.11.2 stable (08:30 UTC) — contenevano un loader inserito in file sorgente legittimi, nascosto con circa 1.000 byte di whitespace padding. Il codice eseguiva come prima riga "off-screen", al di fuori della visualizzazione standard dell'editor.

A differenza della maggior parte degli attacchi npm supply-chain, questa campagna non ha utilizzato script preinstall o postinstall. Secondo Microsoft Threat Intelligence, il malware eseguiva al momento dell'import del modulo tramite require() o import, rendendo inefficace la mitigazione --ignore-scripts. Il primo stage generava un processo Node.js detached con esecuzione nascosta; il secondo scaricava sync.js da IPFS, un bundle di circa 8.2 MB criptato; il terzo attivava il runtime Miasma modulare, composto da circa 92.000 linee di codice.

Il runtime includeva sei moduli implementati ma disabilitati nel build analizzato: credential harvest, encrypted exfiltration, supply-chain propagation, metamorphic generation, AI-tool poisoning, sandbox evasion. Il dossier non specifica se tali moduli siano stati attivati in altri build non analizzati.

Il paradosso della provenance: firme valide, origine tradita

Tutte le versioni malevole sono state pubblicate tramite npm trusted publishing con GitHub OIDC, portando attestations di provenance tecnicamente valide. Secondo Microsoft Threat Intelligence, "le attestations identificavano accuratamente i repository, i commit e i workflow legittimi che avevano creato i pacchetti, anche se i commit triggeranti non erano autorizzati". Questo è il nucleo del paradosso: la firma di integrità ha funzionato esattamente come progettato, ma ha conferito legittimità apparente a codice compromesso a monte.

La fonte non specifica la natura dei dati effettivamente esfiltrati. Il payload si autoidentifica come "M-RED-TEAM v6.4" nei commenti del codice. I meccanismi di persistenza documentati includono: chiave Windows Registry miasma-monitor, servizio systemd utente Linux miasma-monitor.service, e modifiche al profilo shell macOS. I percorsi di installazione di sync.js sono rispettivamente %LOCALAPPDATA%\NodeJS\sync.js, ~/.local/share/NodeJS/sync.js e ~/Library/Application Support/NodeJS/sync.js.

Il C2 primario risiede su 85.137.53.71 porte 8080, 8081 e 8091, con fallback su IPFS (CID QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 e Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf per la variante react-sdk), relay Nostr (relay.damus.io, relay.nostr.com), smart contract Ethereum 0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710, BitTorrent DHT e libp2p. Unit 42 ha identificato il campaign name "miasma-train-p1".

Cosa fare adesso

• Rotazione immediata di credenziali sviluppatore, token GitHub e npm, chiavi cloud (AWS, Azure, GCP) e segreti CI/CD esposti nei repository che hanno importato i pacchetti compromessi.
• Hunting per il file sync.js nei percorsi %LOCALAPPDATA%\NodeJS\, ~/.local/share/NodeJS/ e ~/Library/Application Support/NodeJS/, e per i processi Node.js detached con esecuzione nascosta.
• Purge cache dei package manager e verifica delle dependency lockfile per identificare versioni @asyncapi nella finestra 07:10-08:30 UTC del 14 luglio 2026.
• Revisione delle configurazioni GitHub Actions pull_request_target con checkout di codice PR non trusted, con verifica di eventuali PR aperte da account non riconosciuti negli ultimi 30 giorni.

Le lacune che restano aperte

Il dossier non stabilisce con certezza come il token asyncapi-bot sia stato ottenuto: i log pubblici di Microsoft "non mostrano come la credenziale sia stata acquisita". Non è documentato se la richiesta al dead-drop rentry.co con URL "elzotebo" — collegato a pattern della campagna prt-scan — sia stata effettivamente eseguita e riuscita nel workflow compromesso.

Non emergono sovrapposizioni infrastrutturali che colleghino definitivamente l'attore a threat actor specifici allo stato attuale: Wiz Research dichiara esplicitamente di non effettuare attribuzione definitiva. L'entità completa delle vittime e l'effettiva esfiltrazione di dati rimangono non quantificate. Il collegamento all'incidente Red Hat @redhat-cloud-services di giugno 2026, che ha impiegato lo stesso payload Miasma con initial access diverso, non è stato confermato.

L'evoluzione da attacchi install-time a import-time segnala un adeguamento offensivo contro le difese standard della supply chain JavaScript. Quando la validazione della provenance diventa strumento dell'attaccante piuttosto che sua ostacolo, la linea di demarcazione tra build legittimo e build compromesso si sposta dal registry al repository sorgente — e alla velocità con cui una comunità open source riesce a patchare ciò che sapeva già di avere rotto.

Fonti

• https://cyberpress.org/asyncapi-supply-chain-secrets-theft/
• https://www.wiz.io/blog/m-red-team-asyncapi-supply-chain-compromise-via-github-actions
• https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/
• https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
• https://www.stepsecurity.io/blog/node-ipc-npm-supply-chain-attack