Red Hat: 96 versioni npm avvelenate, worm ruba credenziali

Il 1° giugno 2026 pacchetti @redhat-cloud-services sono stati compromessi via CI/CD. Il malware Miasma sfrutta OIDC, si propaga da solo e resiste alla rimozion…

Contenuto

Red Hat: 96 versioni npm avvelenate, worm ruba credenziali
Red Hat: 96 versioni npm avvelenate, worm ruba credenziali

Il 1° giugno 2026, Aikido Security ha rilevato 96 versioni di 32 pacchetti ufficiali @redhat-cloud-services pubblicati con malware integrato, scaricati complessivamente 116.991 volte a settimana secondo le rilevazioni della stessa Aikido. L'attacco non sfrutta un bug di npm né credenziali rubate a un registry: il vettore è un account GitHub di un dipendente Red Hat compromesso, che ha iniettato commit orfani nei repository RedHatInsights, avvelenando le pipeline CI/CD che pubblicano automaticamente via OIDC. Il risultato è Miasma, variante di Mini Shai-Hulud, un credential-stealing worm con propagazione autonoma, cifratura unica per infezione e persistenza multipla che rende insufficiente la semplice disinstallazione dei pacchetti.

Punti chiave
  • 96 versioni su 32 pacchetti ufficiali, 116.991 download settimanali cumulativi: la scala è registry-wide, non isolata
  • Il vettore è la compromissione di una pipeline CI/CD con trusted publishing OIDC, non un token npm statico rubato
  • Il payload da 4,2 MB usa preinstall hook, quindi esegue durante npm install prima di qualsiasi codice applicativo
  • Propagazione autonoma via bypass_2fa con token npm rubati, cifratura unica per infezione, e persistenza in strumenti AI come Claude Code

Come il CI/CD è diventato il vero bersaglio

L'analisi di Aikido e le attribuzioni di Wiz convergono: l'account GitHub di un dipendente Red Hat è stato compromesso e usato per pushare commit orfani — commit non collegati a pull request né a review — nei repository RedHatInsights/javascript-clients. Da lì, i file di workflow GitHub Actions modificati hanno generato build avvelenate che npm ha pubblicato automaticamente.

Il meccanismo è OIDC trusted publishing: il workflow richiede un token temporaneo tramite id-token: write, si autentica a npm senza credenziali long-lived e pubblica. Aikido lo documenta esplicitamente: "the CI/CD pipeline itself becomes the attack surface, while OIDC-based trusted publishing — designed to eliminate long-lived tokens — becomes a misleading trust signal". Il protocollo funziona come previsto; è la pipeline che produce artefatti malevoli a essere compromessa.

StepSecurity conferma che tutti i pacchetti avvelenati sono stati pubblicati da RedHatInsights/javascript-clients tramite OIDC. La differenza con attacchi precedenti come TanStack e Bitwarden è solo nell'identità del vendor; il pattern è identico.

Anatomia del payload: 4,2 MB di offuscamento a strati

Ogni pacchetto compromesso dichiara uno script preinstall che esegue node index.js automaticamente durante npm install, prima che qualsiasi codice applicativo venga caricato. Questo è documentato da Aikido, Cybersecurity News e StepSecurity.

Il payload misura 4,2 MB secondo Aikido, ed è offuscato in quattro strati documentati da StepSecurity: wrapper try/eval, codifica ROT-21, array di caratteri numerici, cifratura AES-128-GCM con base64 custom, PBKDF2 e cifra di Fisher-Yates. L'esecuzione dinamica analizzata con Harden-Runner ha mostrato lettura da /proc/<pid>/mem con targeting del processo Runner.Worker, uso di ACTIONS_RUNTIME_TOKEN per interrogare l'API GitHub Actions e identificare variabili con flag isSecret, bypassando la mascheratura dei log.

Wiz rileva che la variante Miasma aggiunge collector per identità GCP e Azure, raccogliendo "all identities rather than just secrets". Ogni infezione genera payload con cifratura unica, rendendo inefficaci gli IOC basati su hash.

Exfiltrazione, worm e dead-man switch

L'esfiltrazione primaria punta a api.anthropic.com:443/v1/api, endpoint non valido di Anthropic usato per mimetizzazione, documentato da The Hacker News e Cybersecurity News. Il fallback usa l'API GitHub per creare commit in repository pubblici creati dall'attaccante, con descrizione "Miasma: The Spreading Blight" — confermato da StepSecurity, che ha osservato la creazione di repository e commit via token ghs_*.

La propagazione autonoma è codificata nel malware stesso. StepSecurity ha deoffuscato la chiamata npmPublish(trojan, { bypass_2fa: true }) con autenticazione Bearer: il malware usa token npm rubati per ripubblicare versioni backdoorate dei pacchetti a cui la vittima ha accesso, senza intervento umano dell'attaccante. Questo è worm behavior documentato, non inferenza.

La persistenza si installa su tre fronti: servizio systemd kitty-monitor.service su Linux, com.user.kitty-monitor.plist su macOS, hook SessionStart in Claude Code e tasks.json in VS Code con runOn: folderOpen — tutto documentato da The Hacker News e Cybersecurity News. Socket avverte esplicitamente: "Because the malware includes background execution and potential developer-tool persistence mechanisms, uninstalling the npm package or deleting node_modules should not be considered sufficient cleanup".

Cybersecurity News documenta il dead-man switch gh-token-monitor: se i token rubati vengono revocati prima della rimozione della persistenza, il malware esegue comandi distruttivi incluso il wipe della home directory. La rimozione delle credenziali — azione istintiva — può innescare danni maggiori.

Il contesto: da strumento open-source a campagna di massa

Miasma è una variante di Mini Shai-Hulud, toolkit open-sourced il 12 maggio 2026 dal gruppo TeamPCP secondo Aikido. Il primo commit con stringa "Miasma: The Spreading Blight" è datato 29 maggio 2026 da OX Security riportato da The Hacker News; la compromissione attiva è rilevata il 1° giugno. L'intervallo suggerisce una fase di test, ma il dossier non conferma se il 29 maggio rappresenti già esfiltrazione attiva o sola preparazione.

"Organizations should treat any system that installed one of the affected @redhat-cloud-services package versions as potentially compromised" — Socket researchers, riportato da Ars Technica

Il malware include controlli di evasione: verifica la presenza di CrowdStrike, SentinelOne, Carbon Black e StepSecurity Harden-Runner prima di eseguire, e non si attiva su sistemi in lingua russa — entrambi documentati da The Hacker News e StepSecurity. Questo non costituisce attributione geopolitica: l'open-sourcing del toolkit permette a qualsiasi attore di replicare l'attacco.

Red Hat, via portavoce ad Ars Technica: "The packages are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system". L'azienda sottolinea che l'indagine è in corso, che non è stato identificato impatto su ambienti customer, partner o produzione. Questa affermazione copre i canali ufficiali Red Hat, non l'installazione diretta da npm registry da parte di sviluppatori terzi — che rimane il percorso documentato di esposizione.

Cosa fare adesso

  • Isolare e trattare come compromessi tutti i sistemi che hanno eseguito npm install con pacchetti @redhat-cloud-services nelle versioni indicate dagli IOC di Aikido: la disinstallazione del pacchetto o la cancellazione di node_modules non rimuove la persistenza attiva
  • Ruotare tutte le credenziali GitHub, npm, cloud (AWS/GCP/Azure), Kubernetes, Vault, SSH, Docker registry, GPG esposte sui sistemi coinvolti, tenendo conto che la rotazione prematura di token senza rimozione della persistenza può attivare il dead-man switch
  • Verificare la presenza di servizi kitty-monitor.service, com.user.kitty-monitor.plist, hook Claude Code, e task VS Code runOn: folderOpen su tutti i sistemi di sviluppo che hanno installato pacchetti Red Hat; rimuovere la persistenza prima o contestualmente alla revoca dei token
  • Controllare le public key e i repository GitHub creati recentemente dall'account aziendale: il malware usa repository pubblici come dead-drop per l'esfiltrazione; la presenza di repository con descrizione "Miasma: The Spreading Blight" indica compromissione confermata

Perché questo attacco ridefinisce il perimetro di fiducia

OIDC trusted publishing è stato progettato per eliminare i token long-lived, non per garantire l'integrità della pipeline. L'errore concettuale — documentato dalle stesse fonti primarie — è stato spostare il perimetro di fiducia dal secret al meccanismo di autenticazione, senza estenderlo all'intera catena di produzione. Quando un commit orfano può avvelenare automaticamente decine di pacchetti con 116.991 download settimanali, il problema non è il token.

La cifratura unica per infezione, la persistenza negli strumenti AI di sviluppo, e la propagazione autonoma via registry creano un threat model che supera il rilevamento IOC-based. Il toolkit open-source trasforma un'operazione potenzialmente attribuibile in pattern replicabile da qualsiasi attore con accesso a una pipeline compromessa. La domanda non è chi abbia costruito Miasma, ma quanti attacchi simili il modello OIDC/CI/CD possa ancora facilitare prima che l'industria restringa i permessi di pubblicazione automatica.

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

Fonti

Link utili

Apri l'articolo su DeafNews