Miasma infetta 32 pacchetti npm Red Hat e ruba credenziali cloud

Red Hat rimuove 32 pacchetti npm pubblicati sotto il namespace @redhat-cloud-services dopo la scoperta di un attacco supply chain condotto tramite il worm credential-stealing Miasma, malware progettato per rubare token GitHub, chiavi cloud, credenziali AWS, GCP, Azure, segreti CI/CD, chiavi SSH, token npm, credenziali Docker, token Vault, file .env e configurazioni sensibili degli sviluppatori. L’operazione, individuata il 1 giugno 2026 dai ricercatori di Aikido e OX Security, ha coinvolto 96 versioni backdoorate di librerie interne usate nel tooling di sviluppo Red Hat e distribuite tramite il registro npm, con un volume complessivo stimato in circa 117mila download settimanali. L’attacco è particolarmente rilevante perché non sfrutta un semplice pacchetto typosquatting o una dipendenza sconosciuta, ma colpisce pacchetti associati a un namespace ufficiale e quindi percepiti dagli sviluppatori come affidabili. Gli attaccanti hanno compromesso un account GitHub appartenente a un dipendente Red Hat e lo hanno utilizzato per inserire commit malevoli nei repository ufficiali, pubblicando versioni alterate attraverso il meccanismo di trusted publishing di npm. Ogni pacchetto infetto contiene uno script preinstall che viene eseguito automaticamente durante l’installazione e avvia un payload index.js offuscato da circa 4,2 MB. Miasma, descritto come variante evoluta della famiglia Mini Shai-Hulud, combina furto di credenziali, persistenza nei tool di sviluppo, controllo dell’ambiente di esecuzione, evasione degli strumenti EDR, exfiltrazione cifrata verso repository GitHub pubblici e comportamento distruttivo in caso di revoca dei token rubati. Red Hat ha dichiarato che il codice malevolo era limitato al tooling interno di sviluppo e non ha identificato impatti su ambienti clienti, partner o sistemi di produzione, ma gli sviluppatori che hanno installato le versioni compromesse devono considerare potenzialmente esposti tutti i segreti presenti sulle macchine coinvolte.

I pacchetti @redhat-cloud-services compromessi e l’esposizione degli sviluppatori

La compromissione riguarda esattamente 32 pacchetti pubblicati sotto il namespace @redhat-cloud-services, tra cui componenti come @redhat-cloud-services/chrome nelle versioni 2.3.1 e 2.3.2, @redhat-cloud-services/compliance-client nelle versioni 4.0.3 e 4.0.4, @redhat-cloud-services/config-manager-client nelle versioni 5.0.4 e 5.0.5, @redhat-cloud-services/entitlements-client nelle versioni 4.0.11 e 4.0.12, @redhat-cloud-services/eslint-config-redhat-cloud-services nelle versioni 3.2.1 e 3.2.2, oltre a librerie e componenti collegati a frontend-components, vulnerabilities-client, rbac-client, remediations-client, sources-client e topological-inventory-client. Nel complesso sono state pubblicate 96 versioni malevole, un numero che indica un’operazione automatizzata e non un singolo errore isolato nella catena di rilascio.

Il dato dei circa 116mila-117mila download settimanali rende l’esposizione potenzialmente ampia tra sviluppatori, pipeline interne e ambienti che lavorano su progetti collegati a Red Hat Insights o console.redhat.com. Red Hat ha specificato che i pacchetti erano destinati allo sviluppo interno e non venivano distribuiti ai clienti attraverso il portale console.redhat.com, ma questo non riduce il rischio per gli ambienti di sviluppo che li hanno installati durante la finestra di compromissione. In un attacco supply chain moderno, infatti, l’obiettivo non è necessariamente compromettere direttamente il prodotto finale distribuito al cliente, ma penetrare workstation, pipeline, repository, ambienti CI/CD e identità degli sviluppatori per ottenere credenziali riutilizzabili in altri contesti. Il caso conferma che il registro npm resta una superficie critica per la sicurezza delle aziende tech, perché uno script eseguito al momento dell’installazione può operare prima ancora che lo sviluppatore analizzi o utilizzi realmente il pacchetto.

L’account GitHub compromesso e l’abuso del trusted publishing

Il vettore iniziale dell’operazione passa dalla compromissione di un account GitHub appartenente a un dipendente Red Hat, utilizzato dagli attaccanti per introdurre commit malevoli nei repository ufficiali e avviare la pubblicazione automatica delle versioni backdoorate su npm. Secondo la ricostruzione tecnica, gli aggressori hanno inserito commit orfani che aggiungevano un workflow GitHub Actions e uno script _index.js progettato per sfruttare il meccanismo di trusted publishing. Il workflow richiedeva un token OIDC con permesso id-token: write, autenticava direttamente con l’endpoint npm e pubblicava le versioni infette dei pacchetti indicati nella variabile OIDC_PACKAGES. Questa modalità è particolarmente insidiosa perché trasforma una funzione legittima di sicurezza e automazione in un canale di distribuzione malevolo. Il trusted publishing riduce la necessità di gestire token npm statici, ma se l’account sorgente o il workflow vengono compromessi, l’attaccante può pubblicare pacchetti apparentemente legittimi attraverso una pipeline credibile.

I ricercatori di Aikido hanno individuato il flusso operativo: il workflow installava Bun, eseguiva lo script malevolo e pubblicava automaticamente le versioni infette. Il primo commit contenente la stringa “Miasma: The Spreading Blight” è stato rilevato il 29 maggio 2026, segnale che l’attacco era stato preparato prima della scoperta pubblica del primo giugno. La componente più critica è il bypass dei normali controlli di code review: i commit risultavano riconducibili a un account legittimo, creando un’apparenza di affidabilità sufficiente a superare verifiche superficiali. Questo modello offensivo dimostra che la sicurezza della supply chain non può più limitarsi alla protezione dei token di pubblicazione, ma deve includere protezione degli account GitHub, approvazioni obbligatorie sui workflow, firma dei commit, branch protection, monitoraggio delle modifiche ai file package.json, auditing dei permessi OIDC e controllo continuo delle pipeline.

Lo script preinstall esegue il payload prima del codice applicativo

Ogni pacchetto compromesso dichiarava nel proprio package.json uno script preinstall capace di avviare node index.js automaticamente durante la fase di installazione. Questo dettaglio è fondamentale perché gli script lifecycle di npm vengono eseguiti prima che il codice applicativo venga realmente utilizzato, permettendo al malware di operare appena il pacchetto entra nella macchina dello sviluppatore o nel runner CI/CD. Il payload index.js, grande circa 4,2 MB, era pesantemente offuscato con più livelli di protezione per rallentare analisi statica, reverse engineering e rilevamento automatico. Una volta avviato, Miasma iniziava la raccolta dei dati sensibili e generava payload cifrati unici per ogni infezione, complicando la creazione di firme statiche affidabili. Prima dell’attivazione completa, il worm verificava la presenza di soluzioni di endpoint protection come CrowdStrike, SentinelOne, Carbon Black e StepSecurity Harden-Runner, oltre a controllare la lingua del sistema per evitare l’esecuzione su macchine configurate in russo. Questa logica di esclusione rientra in una prassi già osservata in altre famiglie malware, dove gli operatori evitano determinate giurisdizioni o riducono il rischio di attenzione da parte di ambienti di analisi. L’uso dello script preinstall rende l’attacco molto più pericoloso rispetto a una dipendenza malevola richiamata solo in fase runtime, perché colpisce anche ambienti che installano pacchetti per build, test, linting o gestione di componenti frontend. Uno sviluppatore non deve importare manualmente la libreria compromessa nel proprio codice: basta l’installazione della versione infetta per consentire al payload di eseguire raccolta, persistenza, esfiltrazione e propagazione.

Miasma ruba token cloud, segreti CI/CD e credenziali degli sviluppatori

Il worm Miasma mostra una capacità di raccolta credenziali ampia e orientata agli ambienti di sviluppo moderni. Il malware cerca GitHub Actions secrets, token npm, token PyPI, chiavi AWS access key e session token, credenziali GCP application default, account di servizio GCP, token Azure service principal, identità managed identity, token HashiCorp Vault, token Kubernetes service account, file kubeconfig, chiavi SSH private, chiavi GPG, credenziali Docker registry e qualsiasi file .env presente sul filesystem. La scelta dei target conferma che l’obiettivo non è soltanto rubare password locali, ma acquisire segreti utili a muoversi lateralmente dentro infrastrutture cloud, repository, registri container, pipeline e ambienti orchestrati. L’aggiunta di collector specifici per identità GCP e Azure dimostra un’evoluzione rispetto a varianti meno sofisticate, perché consente al worm di enumerare identità disponibili dalla macchina infetta e catturare credenziali temporanee o permanenti usate nelle pipeline. I dati raccolti vengono cifrati e inviati a repository GitHub pubblici creati automaticamente sull’account della vittima, con descrizione “Miasma: The Spreading Blight”. Come canale alternativo, il malware utilizza l’endpoint api.anthropic.com:443/v1/api come server C2 decoy, una scelta probabilmente pensata per confondere analisti e sistemi di rilevamento che osservano traffico verso servizi AI legittimi. Questa doppia strategia di esfiltrazione aumenta la resilienza dell’attacco e complica la ricostruzione del flusso dati. Per le aziende, il punto più delicato è che una singola workstation infetta può contenere credenziali capaci di aprire accessi a più cloud, più repository e più sistemi di produzione indiretti. La risposta non può quindi limitarsi alla rimozione del pacchetto npm, ma deve includere rotazione sistematica dei segreti, revoca dei token, revisione dei repository, audit dei workflow e controllo di eventuali release generate durante la finestra di esposizione.

Persistenza in VS Code e Claude Code rende il cleanup più complesso

Miasma non opera come semplice stealer one-shot, ma introduce meccanismi di persistenza dentro strumenti comunemente usati dagli sviluppatori. Il worm inietta hook in Anthropic Claude Code tramite SessionStart e modifica configurazioni di Visual Studio Code, in particolare file come tasks.json, per assicurarsi nuove esecuzioni anche dopo la rimozione iniziale del pacchetto compromesso. Questa scelta dimostra una conoscenza precisa delle abitudini degli sviluppatori moderni, che lavorano sempre più spesso con editor estendibili, task automatizzati, assistenti AI da terminale e workflow locali integrati. Il malware tenta anche escalation di privilegi tramite container con bind mount di /etc/sudoers.d, con l’obiettivo di ottenere sudo senza password e aumentare la propria capacità di controllo sulla macchina. Il comportamento più aggressivo riguarda la risposta alla revoca dei token rubati: se gli attaccanti rilevano che i token vengono invalidati, il malware può attivare un comportamento distruttivo e cancellare la macchina compromessa. Il messaggio di commit includeva la stringa “IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner” seguita dal token stesso, una minaccia esplicita che trasforma la gestione dell’incidente in una procedura più delicata. La presenza di persistenza e potenziale distruzione significa che eliminare node_modules, disinstallare il pacchetto o ripulire la cache npm non basta. Gli host coinvolti devono essere isolati dalla rete, analizzati per artefatti persistenti, controllati nei file di configurazione degli strumenti di sviluppo e, nei casi più sensibili, ricostruiti da immagini pulite. La risposta deve inoltre coordinare revoca dei token e contenimento dell’host, evitando di lasciare il malware attivo mentre i segreti vengono invalidati.

Red Hat rimuove i pacchetti e circoscrive l’impatto al tooling interno

Red Hat ha reagito rimuovendo dal registro npm tutti i pacchetti compromessi appena ricevuta la segnalazione. L’azienda ha confermato di essere a conoscenza delle segnalazioni di sicurezza relative ad alcuni pacchetti npm nel proprio ecosistema di tooling di sviluppo, di aver avviato immediatamente un’indagine e di aver rimosso i pacchetti dal registro. Red Hat ha inoltre precisato che i pacchetti erano strettamente limitati allo sviluppo interno e che il codice malevolo non era stato pubblicato per consumo dei clienti tramite console.redhat.com. Secondo la comunicazione aziendale, al momento dell’indagine non risultano impatti identificati su ambienti clienti, partner o sistemi di produzione Red Hat. Questa distinzione è importante perché separa il rischio per gli ambienti interni di sviluppo dal rischio diretto per i clienti finali, ma non elimina la gravità dell’incidente supply chain. L’abuso di un account GitHub compromesso, la pubblicazione su npm, il volume di download e le capacità di furto credenziali del worm mostrano quanto un attacco contro il tooling possa diventare pericoloso anche se non raggiunge immediatamente il prodotto distribuito. Gli ambienti di sviluppo custodiscono spesso chiavi cloud, permessi CI/CD, segreti di staging, credenziali container e accessi a repository privati. Per questo Red Hat continua a indagare sulle modalità di compromissione dell’account GitHub e sulla catena di pubblicazione che ha permesso alle versioni malevole di raggiungere il registro npm. La risposta tempestiva riduce la finestra di esposizione futura, ma gli effetti dell’installazione su singole workstation o runner CI/CD devono essere gestiti dai team che hanno scaricato le versioni infette.

Gli sviluppatori devono ruotare credenziali e verificare pipeline CI/CD

Gli sviluppatori che hanno installato una delle versioni compromesse a partire dal 1 giugno 2026 devono considerare potenzialmente compromessi tutti i segreti accessibili dal dispositivo infetto. La priorità è isolare l’host, interrompere eventuali workflow attivi, rimuovere le versioni malevole e procedere alla rotazione immediata di token GitHub Actions, chiavi AWS, credenziali GCP, token Azure, token npm, chiavi SSH, credenziali Docker, token Vault, credenziali Kubernetes e segreti presenti nei file .env. La verifica deve includere artefatti di persistenza in percorsi come ~/.claude/settings.json, file .vscode/tasks.json, workflow GitHub Actions aggiunti o modificati, repository pubblici creati automaticamente sull’account della vittima e commit anomali contenenti descrizioni o messaggi associati a Miasma. Nei contesti CI/CD, la risposta deve essere ancora più rigorosa: sospensione temporanea dei workflow, invalidazione degli artifact prodotti durante la finestra di esposizione, verifica delle immagini container, controllo dei pacchetti pubblicati downstream e audit delle release generate dopo l’installazione dei pacchetti compromessi. È essenziale controllare anche eventuali token temporanei o credenziali di sessione, perché il malware raccoglie sia segreti persistenti sia identità cloud disponibili al momento dell’esecuzione. La rotazione deve seguire un ordine operativo sicuro: prima isolamento e contenimento dell’host, poi revoca dei token, quindi verifica di eventuali persistenze e infine ripristino da ambiente pulito. Un cleanup incompleto rischia di consentire al worm di rieseguire payload o di sfruttare segreti non ancora ruotati.

Miasma conferma l’evoluzione della famiglia Shai-Hulud

Miasma viene descritto come variante avanzata di Mini Shai-Hulud, a sua volta collegata alla famiglia Shai-Hulud resa pubblica da TeamPCP. Rispetto alle versioni precedenti, il worm aggiunge più livelli di offuscamento, meccanismi di consegna multi-stage, collector cloud specifici, controlli anti-EDR e capacità di persistenza nei tool di sviluppo. La campagna non nasce con Red Hat: dal mese di aprile 2026 ha colpito oltre 300 repository GitHub e si inserisce in una sequenza di compromissioni che ha già coinvolto pacchetti e progetti associati a @bitwarden/cli, componenti SAP, PyTorch Lightning, Mistral, TanStack e Microsoft DurableTask. Il tratto comune è l’abuso di account GitHub compromessi e pipeline di pubblicazione per diffondere pacchetti malevoli su ecosistemi come npm e PyPI. Questa evoluzione indica che gli attaccanti non puntano più solo alla pubblicazione di pacchetti isolati, ma cercano di inserirsi nei processi legittimi di release, sfruttando fiducia, automazione e velocità delle pipeline moderne. Miasma mantiene tattiche già note come esecuzione all’installazione, harvesting delle credenziali e targeting CI/CD, ma le combina con capacità più aggressive di persistenza ed exfiltrazione. Il risultato è un malware capace di trasformare ogni installazione in un punto di raccolta segreti e potenziale propagazione downstream. Per la sicurezza applicativa, questo incidente conferma che la difesa deve spostarsi a monte: controllo delle dipendenze, analisi degli script lifecycle, blocco o revisione degli script preinstall, validazione delle versioni, protezione degli account GitHub, monitoraggio dei workflow e verifica della provenienza degli artifact.

GitHub pubblico e decoy Anthropic complicano l’esfiltrazione

L’esfiltrazione di Miasma si basa su un modello progettato per nascondersi dentro servizi legittimi e ridurre la visibilità dei canali malevoli tradizionali. I dati rubati vengono cifrati in envelope e pubblicati tramite commit su repository GitHub pubblici creati automaticamente sull’account della vittima, ciascuno con descrizione “Miasma: The Spreading Blight”. Il malware utilizza l’API GitHub GraphQL per creare commit su branch che possono apparire come modifiche verificate, aumentando la confusione tra attività legittima e attività malevola. Come fallback o canale alternativo, il worm sfrutta api.anthropic.com:443/v1/api come server C2 decoy, scelta particolarmente significativa in un periodo in cui molti ambienti di sviluppo comunicano regolarmente con strumenti AI e API di assistenti generativi. Il traffico verso domini associati ad AI o piattaforme note può risultare meno sospetto nei log aziendali, soprattutto se l’organizzazione consente l’uso di strumenti come Claude Code o altri assistenti da terminale. Questo approccio conferma una tendenza più ampia: gli attaccanti cercano di confondere i confini tra servizi produttivi legittimi e infrastrutture di comando, usando piattaforme cloud, repository pubblici e API note come copertura. Per difendersi non basta bloccare domini sconosciuti. Serve monitorare la creazione anomala di repository, commit inattesi da workstation sviluppatori, uso insolito di API GraphQL, traffico verso endpoint non coerenti con i workflow dichiarati e comparsa di descrizioni o stringhe riconducibili alla campagna. La sicurezza deve diventare comportamentale, perché gli indicatori statici possono cambiare rapidamente mentre il modello operativo resta riconoscibile.

Il caso Red Hat mostra il nuovo rischio delle pipeline software

L’attacco ai pacchetti @redhat-cloud-services dimostra che le pipeline software moderne sono diventate bersagli di primo livello. Gli attaccanti non hanno bisogno di violare direttamente un ambiente di produzione se possono compromettere un account GitHub, alterare workflow, pubblicare versioni su npm e attendere che sviluppatori o runner CI/CD eseguano automaticamente il payload. Questo modello sfrutta la fiducia distribuita che regge lo sviluppo open source e enterprise: namespace ufficiali, automazioni di pubblicazione, trusted publishing, dipendenze interne e processi di installazione rapidi. Miasma colpisce proprio questo punto cieco, perché si attiva nel momento in cui il pacchetto viene installato e raccoglie i segreti che rendono possibile il movimento successivo. La campagna mostra anche che il problema del malware su npm non riguarda soltanto pacchetti sconosciuti o nomi ingannevoli, ma può investire namespace legittimi quando l’identità di pubblicazione viene compromessa. Le raccomandazioni di Aikido e OX Security vanno nella direzione di un rafforzamento sistemico: verificare le versioni installate dei pacchetti @redhat-cloud-services, tornare immediatamente a versioni sicure, abilitare 2FA ovunque possibile, monitorare repository GitHub per commit non autorizzati, proteggere workflow CI/CD, limitare i permessi OIDC, controllare gli script lifecycle npm e migliorare il rilevamento automatico dei pacchetti malevoli prima che raggiungano migliaia di download. L’incidente conferma che la supply chain non è più un rischio laterale, ma una superficie centrale della sicurezza enterprise. Quando un worm come Miasma entra nel ciclo di sviluppo, il bersaglio reale non è solo il pacchetto compromesso, ma l’intero ecosistema di fiducia che consente al software moderno di essere costruito, pubblicato e distribuito.