AsyncAPI: 5 pacchetti npm malevoli con attestati SLSA validi…

L'attacco alla supply chain AsyncAPI ha dimostrato che attestazioni di provenienza crittografiche e trusted publishing possono essere strumenti dell'attaccante

Il 14 luglio 2026, tra le 07:10 e le 11:18 UTC, cinque versioni malevole di pacchetti npm del progetto AsyncAPI sono rimaste disponibili al download con attestazioni di provenienza SLSA perfettamente valide. Gli attaccanti non hanno rubato token npm né violato il registro: hanno compromesso due repository GitHub sfruttando una workflow mal configurata, poi hanno usato le pipeline CI/CD legittime con OIDC trusted publishing per firmare crittograficamente il malware. Il risultato è una distribuzione che appare tecnicamente ineccepibile.

L'esecuzione avviene al caricamento del modulo (require()), non durante npm install. Questo dettaglio rende inutile la mitigazione standard --ignore-scripts e costringe a ripensare i presupposti della sicurezza della supply chain JavaScript.

Punti chiave

Cinque versioni malevole pubblicate su quattro pacchetti @asyncapi con oltre 2,25 milioni di download settimanali cumulativi, secondo BleepingComputer
Le attestazioni SLSA su Sigstore/Fulcio erano autentiche: certificavano che il workflow autorizzato aveva prodotto il pacchetto, non che il commit di origine fosse legittimo
L'esecuzione al module-load time bypassa --ignore-scripts; il malware si attiva quando un'applicazione chiama require(), non durante l'installazione
Il payload Miasma usa sei canali C2 indipendenti (HTTP, Nostr, IPFS, BitTorrent DHT, libp2p GossipSub, smart contract Ethereum) con persistenza cross-platform
La vulnerabilità pull_request_target era nota da aprile 2026: una proof of concept era stata presentata ma la pull request di fix era rimasta aperta e non mergiata

Come i repository sono stati compromessi

L'attacco ha preso di mira due repository: asyncapi/generator (branch next) e asyncapi/spec-json-schemas (branch master). Il primo push malevolo, con commit SHA 3eab3ec9304aa26081358330491d3cfeb55cc245, è arrivato sul branch next alle 06:58:42 UTC, come documentato da StepSecurity. Dodici secondi dopo il push, la workflow GitHub Actions ha eseguito il rilascio.

Il meccanismo non sfruttava una vulnerabilità zero-day in GitHub Actions, ma una configurazione pericolosa già nota. Secondo i ricercatori Rami McCarthy e Merav Bar di Wiz, il repository asyncapi/generator conteneva una workflow file che usava pull_request_target per attivarsi sulle pull request, ma eseguiva il checkout del codice della pull request invece che del branch base. Questo è critico perché pull_request_target opera nel contesto del repository base con accesso completo ai segreti.

L'identità git usata per i commit era un placeholder: "Your Name" con indirizzo you@example.com e login GitHub "invalid-email-address". Il dossier non specifica se questo indichi un personal token compromesso, una GitHub App violata o un altro meccanismo di accesso push.

Il paradosso della provenienza: quando la firma crittografica inganna

Il punto di svolta tecnico dell'attacco è nella produzione di attestazioni SLSA valide su pacchetti malevoli. StepSecurity ha analizzato i certificati Fulcio di Sigstore: ogni pacchetto portava metadati che registravano repo:asyncapi/generator:ref:refs/heads/next, il file workflow esatto, lo SHA del commit e l'URL della run.

Come ha osservato il ricercatore Rohan Prabhu di StepSecurity: "Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers". La distinzione è sostanziale: il meccanismo di trusted publishing con OIDC ha funzionato esattamente come progettato, conferendo autenticità crittografica a codice iniettato dall'esterno. Provenance e legittimità del codice sono diventate categorie disgiunte.

"The resulting packages carry legitimate SLSA provenance attestations, proving only that the project's authorized workflow produced them, not that the triggering commits were legitimate. Provenance does not protect against a compromised push credential." — StepSecurity

L'esecuzione al require() e il bypass di --ignore-scripts

La maggior parte delle difese della supply chain npm si concentra sui lifecycle scripts (preinstall, postinstall). Gli utenti esperti usano npm install --ignore-scripts per neutralizzare payload che si attivano in questa fase. Questo attacco ignora completamente quel vettore.

Il codice malevolo è un implant JavaScript offuscato di circa 7,7 KB iniettato nei file del pacchetto. Quando un'applicazione o una CI/CD esegue require() sul modulo, il dropper si attiva: genera un processo Node.js staccato che scarica un secondo stadio. Secondo Microsoft: "Because the trigger is an import rather than an install script, the common npm install --ignore-scripts mitigation does not neutralize it". StepSecurity conferma: "This dropper fires when the poisoned module is require()d during normal use of the generator: the moment a build or CI job actually calls into the library, not at npm install time".

Il secondo stadio è un file sync.js criptato di circa 8,25 MB, scaricato da IPFS tramite due CID distinti per i due repository attaccati: QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 per generator e Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf per spec-json-schemas. La decrittografia usa HKDF-SHA256 e AES-256-GCM, producendo un payload Miasma di 3,09 MB.

Miasma: un framework modulare con sei canali C2

Il payload finale è il framework Miasma, composto da 744 moduli secondo The Hacker News. La sua architettura C2 è progettata per la resilienza: sei canali indipendenti riducono la dipendenza da un singolo punto di controllo. Oltre all'HTTP classico, il framework usa Nostr relay, IPFS, BitTorrent DHT, libp2p GossipSub mesh P2P e smart contract Ethereum per ricevere comandi e distribuire aggiornamenti.

I meccanismi di persistenza coprono Linux (systemd, crontab), macOS (launchd) e Windows (Registry autostart). L'anti-analisi include rilevamento di sandbox e VM, verifica della lingua russa, dead man's switch su token rubato ed evasione di otto tool di sicurezza: CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium e Qualys.

Nonostante il branding Miasma, l'attribuzione resta incerta. OX Security, tramite il ricercatore Moshe Siman Tov Bustan, nega esplicitamente il collegamento con campagne precedenti: "this malware isn't the same as [past Miasma/Shai-Hulud/TeamPCP campaigns], nor is it attributed to them". SafeDep suggerisce invece "either a private, parallel build by the same operators or a separate group that adopted the Miasma brand after the source was published". Aikido Security aggiunge cautela: "The Miasma branding may reflect code reuse, imitation, or deliberate mislabeling. No definitive attribution is made here".

Microsoft traccia il malware come MiasmStealer/Supychain. Le funzionalità di furto credenziali, poisonining di tool AI e propagazione nel registro erano presenti nel codice ma toggled off, secondo Microsoft e Aikido: il dossier non chiarisce se per deployment incompleto o staging deliberato.

Cosa fare adesso

Le azioni prioritarie per i team che usano AsyncAPI o gestiscono pipeline simili:

Auditare le workflow pull_request_target in tutti i repository: verificare che eseguano checkout del branch base, non del codice della pull request, e che non abbiano accesso a segreti se non strettamente necessario
Ispezionare i log di build e CI/CD tra le 07:10 e le 11:18 UTC del 14 luglio 2026 per rilevare require() di pacchetti @asyncapi nelle versioni compromesse, non solo esecuzioni di install scripts
Implementare monitoraggio della rete in runtime nelle pipeline CI/CD: StepSecurity ha confermato l'IP C2 85.137.53.71 tramite telemetry Harden-Runner che ha bloccato connessioni a 85.137.53.71:8080, dht.transmissionbt.com e router.bittorrent.com alle 08:59:49-50 UTC
Rivedere la politica di trust delle attestazioni SLSA: la presenza di un attestato Sigstore non sostituisce il controllo del codice sorgente e della configurazione workflow che l'ha generato

Perché questo attacco cambia i termini della supply chain

L'incidente AsyncAPI non è una storia di token rubati o di registro npm violato. È la dimostrazione che le infrastrutture di sicurezza introdotte per risolvere problemi precedenti—provenance attestations, OIDC trusted publishing, SLSA—possono diventare elementi dell'attacco quando l'avversario sposta il bersaglio upstream, sulla pipeline stessa. La firma crittografica diventa velo, non scudo.

Il module-load execution impone un cambio di paradigma: la difesa non può più fermarsi ai confini dell'installazione. E la proof of concept nota da aprile 2026, con fix non mergiato al momento dell'attacco, solleva una questione di governance: quante vulnerabilità di configurazione già documentate attendono nella coda delle pull request dei progetti open source critici?

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

Fonti

Fonti e riferimenti