Il 1º giugno 2026 i pacchetti npm di Red Hat hanno iniziato a distribuire un payload nascosto in un file da 157 byte. Entro il 24 giugno la campagna Miasma aveva compromesso almeno 109 pacchetti, superato il mezzo milione di download mensili infetti, e dimostrato che l'intero ambiente di sviluppo — non solo il package manager — è diventato superficie di attacco. La novità tecnica decisiva: Phantom Gyp, una tecnica che esegue codice arbitrario durante npm install senza dichiarare alcuno script nel package.json, rendendo il payload invisibile agli strumenti di monitoraggio standard.
- Phantom Gyp sfrutta la sintassi di sostituzione comando di node-gyp in binding.gyp per eseguire codice senza lifecycle scripts in package.json, aggirando i controlli di sicurezza standard su npm install.
- Il payload scarica il runtime Bun v1.3.13 da GitHub per evadere la telemetria Node.js, quindi estrae segreti GitHub Actions leggendo la memoria del processo Runner.Worker in /proc/{pid}/mem.
- L'esfiltrazione avviene esclusivamente tramite API GitHub autenticate verso repository controllati dall'attaccante, senza contatto con domini C2 esterni, rendendo il traffico indistinguibile da quello legittimo.
- La campagna ha superato l'ecosistema npm: il 24 giugno ha colpito 20 pacchetti LeoPlatform in una finestra di pubblicazione di 3 secondi, il modulo Go Verana Blockchain, e 13 strumenti di assistenza AI codice inclusi Claude, Copilot e Gemini.
Phantom Gyp: l'installazione invisibile
Il cuore tecnico della campagna risiede in un file binding.gyp di 157 byte. Secondo StepSecurity, il file contiene la riga <!(node index.js > /dev/null 2>&1 && echo stub.c) nell'array sources. La sintassi <! attiva la sostituzione comando di node-gyp: durante la fase di build, il sistema esegue node index.js e ne nasconde l'output, quindi procede con l'installazione senza segnalazioni visibili.
Il package.json associato non dichiara alcun campo scripts. Questo dettaglio architetturale è determinante: gli strumenti che bloccano o loggano gli script postinstall, preinstall e install — la difesa standard contro i pacchetti npm malevoli — non rilevano alcuna anomalia. Il codice viene eseguito in una fase di build che la maggior parte delle organizzazioni non monitora con la stessa attenzione riservata ai lifecycle scripts.
"Qualsiasi pacchetto che distribuisce un binding.gyp senza sorgenti C++ e senza output .node dovrebbe essere considerato sospetto." — StepSecurity
La telemetria di Harden-Runner cattura la sequenza completa: curl scarica bun-v1.3.13/bun-linux-x64-baseline.zip dai release GitHub, unzip lo estrae, e bun esegue il payload entro un secondo. Il runtime Bun, progettato per compatibilità con Node.js ma con engine diverso, elude i controlli basati su node e le regole di detection specifiche dell'ecosistema JavaScript tradizionale.
La memoria del runner come miniera di segreti
Una volta attivo, il payload non si limita a raccogliere variabili d'ambiente o log di build. Secondo l'analisi di StepSecurity, il malware identifica il processo Runner.Worker di GitHub Actions, ne ottiene il PID, e legge direttamente /proc/{pid}/mem con privilegi elevati tramite sudo. Da questa lettura estrae i valori contrassegnati come segreti nel workflow — quelli che GitHub Actions maschera nei log con la sintassi *** — bypassando completamente il meccanismo di log masking.
I materiali raccolti vengono cifrati e trasmessi tramite chiamate API GitHub autenticate. L'attaccante non necessita di infrastruttura C2 dedicata: crea repository pubblici con descrizioni come "Miasma: The Spreading Blight" o il reverse di "Shai-Hulud: Here We Go Again", e vi carica i dati usando i token della vittima. StepSecurity ha identificato 236 repository sull'account liuende501 utilizzati come dead drop per le credenziali, mentre The Hacker News riporta 559 repository pubblici con la descrizione "Alright Lets See If This Works".
Questa architettura di esfiltrazione presenta un problema di rilevamento fondamentale. Il traffico verso api.github.com è legittimo per definizione in un ambiente CI/CD: gli strumenti di network detection non segnalano anomalie, e la compromissione si manifesta solo quando il token viene riutilizzato per azioni non autorizzate.
Red Hat: quando la provenienza è la trappola
Il 1º giugno la campagna ha colpito l'account npm @redhat-cloud-services con 32 pacchetti e una media di circa 80.000 download settimanali. Secondo Wiz, l'accesso iniziale è avvenuto tramite un account GitHub dipendente Red Hat compromesso, utilizzato per pushare commit orfani che aggiravano il code review. I pacchetti venivano pubblicati con attestazioni SLSA valide: la pipeline di build compromessa generava provenance tecnicamente corretta, rendendo impossibile la verifica della compromissione basata esclusivamente su metadati di supply chain.
Il payload di questa ondata raggiungeva 4,29 MB — un incremento di 25 volte rispetto al file originale di circa 200 KB — con quattro livelli di offuscamento. Secondo l'analisi di Unit 42, questo approccio riflette una strategia di "cambiare indicatori il minimo indispensabile per rendere meno efficaci le detection basate su firme obsolete".
Il 3 giugno una seconda ondata ha compromesso 57 pacchetti in 286 versioni malevole, con durata complessiva inferiore alle due ore. Tra questi, @vapi-ai/server-sdk con oltre 408.000 download mensili. Il 24 giugno, 20 pacchetti LeoPlatform sono stati pubblicati in una finestra coordinata di 3 secondi alle 23:04:55 UTC, con download settimanali combinati di circa 13.600. StepSecurity ha verificato che il toolkit è identico byte per byte a quello del 3 giugno: stesso binding.gyp, stesso URL di download Bun, stesso blob downloader di 907 byte.
Dal codice all'IDE: l'espansione oltre npm
La campagna ha superato i confini dell'ecosistema npm con due vettori distinti. Il modulo Go github.com/verana-labs/verana-blockchain@v0.10.1-dev.20 non utilizza binding.gyp — irrilevante per Go — ma invece include file di configurazione per VS Code e Claude attivati all'apertura della cartella nell'IDE, secondo quanto documentato da The Hacker News e CyberPress. Questa è un'esecuzione source-repository, non build-time: il repository stesso diventa veicolo di infezione quando clonato o aperto in un editor.
Il 24 giugno alle 15:39:06 UTC, l'azione GitHub codfish/semantic-release-action è stata compromessa tramite force-push con redirezione di sette tag. StepSecurity riporta che l'attaccante ha creato Repository Rulesets per impedire il ripristino da parte dei maintainer. Il payload di 512 KB ruba token OIDC e PAT, li cifra con AES-128-GCM, e tenta la propagazione di backdoor in altri repository accessibili con le credenziali sottratte. Il marker di relay token è evoluto da "IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner" a "RevokeAndItGoesKaboom".
La componente più recente riguarda la persistenza negli strumenti di assistenza AI al codice. Il payload di codfish targets 13 strumenti — Claude, Codex, Gemini, Copilot, Kiro, OpenCode, Cline, Aider, Tabby, Amazon Q, Cody, Bolt, Continue — iniettando hook SessionStart e commenti che attivano esecuzione in background invisibile. Questo significa che uno sviluppatore che apre un repository in VS Code con estensione AI installata può attivare il payload senza aver mai eseguito npm install o go mod download.
Cosa fare adesso
- Audit immediato delle dipendenze: verificare la presenza di binding.gyp in pacchetti npm privi di sorgenti C++ o output binario .node, con particolare attenzione alle versioni pubblicate tra il 1º e il 24 giugno 2026.
- Rotazione completa di tutti i token GitHub Actions, OIDC e PAT esposti in pipeline CI/CD, inclusi quelli con scadenza apparentemente sicura: il malware estrae i valori dalla memoria prima che possano essere revocati.
- Ispezione delle configurazioni degli strumenti AI di codice in ~/.config e directory equivalenti per rilevare hook SessionStart non autorizzati, con particolare attenzione a Claude, Copilot, Gemini e Cody.
- Verifica dei repository Actions e dei tag di rilascio: controllare che nessuna azione GitHub utilizzata nei workflow abbia subito force-push o redirezione tag, con particolare attenzione a codfish/semantic-release-action.
Perché questo cambia il perimetro della sicurezza
Miasma dimostra che il perimetro di attacco del software non è più il package manager ma l'intero flusso di lavoro dello sviluppatore. La catena di compromissione inizia con npm install, ma prosegue attraverso la memoria del CI runner, le API GitHub, e infine l'IDE con assistenza AI. Ogni anello è legittimo isolatamente: il traffico verso GitHub è autorizzato, l'apertura di un repository è normale, l'esecuzione di Bun in CI è prevista. La sofisticazione sta nell'assemblaggio, non nei singoli componenti.
Il passaggio da Shai-Hulud a Miasma — la stessa infrastruttura con nuovi indicatori e superfici di attacco — suggerisce un gruppo che investe nella longevità operativa piuttosto che nell'impatto massiccio immediato. Secondo JFrog, citato da The Hacker News: "La storia rilevante non è che il payload sia radicalmente nuovo. È che Shai-Hulud continua a muoversi attraverso ecosistemi legittimi di pacchetti cambiando indicatori sufficienti a rendere meno efficaci le detection obsolete". La domanda per le difese non è più se un pacchetto è malevolo, ma se qualsiasi interazione con qualsiasi repository — clone, install, apertura — può attivare una compromissione.
FAQ
- Phantom Gyp funziona anche con yarn o pnpm?
- Il brief documenta esclusivamente l'uso con npm install tramite node-gyp. Non emergono verifiche su yarn, pnpm o altri gestori di pacchetti.
- I pacchetti compromessi sono ancora disponibili su npm?
- Le fonti primarie non documentano lo stato attuale di disponibilità dei pacchetti: alcune versioni potrebbero essere state ritirate, altre potrebbero persistere nei mirror e nella cache dei registry aziendali.
- La persistenza AI richiede privilegi amministrativi?
- Il dossier non specifica il livello di privilezi richiesto per l'iniezione dei hook SessionStart negli strumenti AI: i file di configurazione target risiedono tipicamente in ~/.config, accessibile all'utente standard.
Fonti
- https://thehackernews.com/2026/06/miasma-malware-targets-npm-packages-and.html
- https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
- https://www.darkreading.com/cyber-risk/malicious-openclaw-skills-clawhub-threaten-ai-supply-chain
- https://www.infosectoday.io/miasma-malware-targets-npm-packages-and-github-actions-in-supply-chain-attack/
- https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm
- https://www.wiz.io/blog/miasma-supply-chain-attack-targeting-redhat-npm-packages
- https://cyberpress.org/shai-hulud-hits-npm-go/
- https://www.stepsecurity.io/blog/mass-npm-supply-chain-attack-20-leo-platform-packages-compromised
- https://www.stepsecurity.io/blog/supply-chain-compromise-codfish-semantic-release-action
- https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised
- https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932681873
- https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932729784?jobId=79455619199
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.