Red Hat, 32 pacchetti npm compromessi: il paradosso del "trusted publishing"

Il 1° giugno 2026, Aikido e OX Security hanno scoperto che più di 30 pacchetti npm del namespace @redhat-cloud-services distribuivano da ore una variante del m…

Contenuto

Red Hat, 32 pacchetti npm compromessi: il paradosso del "trusted publishing" {"main_topic":"cybersecurity","topics":["cybersec","malware","infostealer","opensource","bigtech"]} ```

Il 1° giugno 2026, Aikido e OX Security hanno scoperto che più di 30 pacchetti npm del namespace @redhat-cloud-services distribuivano da ore una variante del malware Shai-Hulud, ribattezzata Miasma. Il vettore non era una falla di npm né un furto di token a lunga scadenza, ma l'abuso di un meccanismo di sicurezza: l'OIDC trusted publishing di GitHub Actions, progettato proprio per eliminare i token tradizionali. Un account GitHub di un dipendente Red Hat compromesso ha generato commit orfani, attivato workflow malevoli e ottenuto token OIDC short-lived per pubblicare versioni backdoorate, dimostrando che "di breve durata" non equivale a "a basso rischio".

Punti chiave

32 pacchetti e 96 versioni del namespace @redhat-cloud-services sono stati compromessi attraverso l'abuso di GitHub Actions OIDC trusted publishing da un account dipendente violato.
Il payload Miasma, variante di Shai-Hulud/Mini Shai-Hulud, si attiva automaticamente all'installazione via preinstall hook, eseguendo un file JavaScript offuscato da 4,2 MB con catena di deoffuscazione ROT-21 → AES-128-GCM → runtime Bun.
Il malware ruba credenziali da ambienti cloud, CI/CD, strumenti di sviluppo e chiavi SSH, exfiltra dati camuffandoli come traffico Anthropic API, e si auto-propaga come worm usando il parametro bypass_2fa per aggirare l'autenticazione a due fattori di npm.
Red Hat ha rimosso i pacchetti e dichiarato che nessun cliente è stato impattato tramite console.redhat.com, ma i pacchetti erano disponibili per circa 80.000-117.000 download settimanali secondo stime di Wiz e Aikido.

Come un account interno ha bypassato la revisione del codice

L'attacco è iniziato con il compromesso di un account GitHub di un dipendente Red Hat, non con una violazione dell'infrastruttura npm o GitHub. Secondo l'analisi di Aikido, l'attaccante ha pushato commit orfani direttamente su due repository RedHatInsights, aggirando completamente la review obbligatoria. Questi commit introducevano un workflow GitHub Actions (ci.yaml) e uno script (_index.js) che sfruttava il permesso id-token: write per richiedere token OIDC short-lived da GitHub e autenticarsi con l'endpoint npm di trusted publishing.

StepSecurity ha confermato che tutti i pacchetti compromessi sono stati pubblicati via OIDC dal repository RedHatInsights/javascript-clients. Il meccanismo OIDC trusted publishing, introdotto da npm proprio per sostituire i token statici e limitarne la durata, qui si è trasformato in un'arma: il token era legittimo, temporaneo, eppure sufficiente a iniettare codice malevolo nella catena di approvvigionamento di decine di migliaia di sviluppatori.

La discrepanza nei numeri di download — circa 117.000 secondo Aikido, circa 80.000 secondo Wiz — riflette metodologie di conteggio diverse e istantanee temporali separate, non una contraddizione sostanziale. Entrambe le fonti concordano sull'ordine di grandezza: decine di migliaia di installazioni potenziali in pochi giorni.

L'anatomia del payload: 4,2 MB di offuscamento a più stadi

Ogni pacchetto compromesso dichiarava uno script preinstall in package.json che eseguiva node index.js. StepSecurity ha documentato che l'esecuzione inizia nel momento stesso in cui npm install elabora il pacchetto, prima che qualsiasi codice applicativo venga importato. Il file index.js pesa 4,2 MB e nasconde il payload reale sotto tre strati separati di offuscamento.

JFrog Security Research ha ricostruito la catena: il primo strato ricostruisce JavaScript da un grande array numerico, applica una trasformazione di tipo ROT-21, poi rimuove il wrapper. Lo stadio successivo decripta due blob AES-128-GCM. Il risultato è un bootstrapper che scarica il runtime Bun da GitHub releases (versione 1.3.13 per Linux, macOS e Windows) se non presente, scrive il payload principale in un file transitorio sotto /tmp/p*.js, lo esegue con Bun e lo elimina.

La variante Miasma, identificata per la prima volta dalla stringa "Miasma: The Spreading Blight" in descrizioni di repository GitHub con commit risalente al 29 maggio 2026, introduce due novità rispetto a Shai-Hulud originale: collettori per identità GCP e Azure, che indicano una focalizzazione accresciuta sull'accesso cloud, e un payload unico per ogni infezione, criptato con chiave derivata tramite PBKDF2 con 200.000 iterazioni, rendendo il tracking delle versioni significativamente più complesso.

"Il payload legge da /proc/ /mem per estrarre segreti live direttamente dalla memoria del processo Runner.Worker." — StepSecurity

Come il malware sottrae segreti e aggira le protezioni CI/CD

Il furto di credenziali non si limita a file statici. StepSecurity ha documentato in ambiente controllato che il payload legge direttamente dalla memoria di processo di GitHub Actions, targettizzando variabili contrassegnate come isSecret: true nel runtime API. Questa tecnica bypassa il log masking standard di GitHub Actions, che oscura i segreti nei log ma non li protegge dall'accesso diretto alla memoria del worker.

JFrog ha identificato l'intero ventaglio di obiettivi: segreti GitHub Actions, credenziali AWS/GCP/Azure, token Kubernetes e Vault, chiavi SSH, token npm e PyPI, credenziali Docker, chiavi GPG e file .env. L'esfiltrazione avviene attraverso due canali: un endpoint camuffato da API Anthropic (api.anthropic.com/v1/api, non una rotta valida, che restituisce errore 404 in stile API Anthropic) e repository GitHub usati come dead-drop. Il dominio Anthropic serve esclusivamente a mimetizzare il traffico malevolo; non emergono evidenze di coinvolgimento dell'infrastruttura Anthropic.

La capacità di auto-propagazione distingue Miasma da infostealer passivi. Usando token npm rubati con il parametro bypass_2fa: true — funzionalità disponibile per token di automazione — il malware può ripubblicare versioni backdoorate anche contro account protetti da autenticazione a due fattori. Questo meccanismo trasforma l'infezione in un worm in grado di diffondersi autonomamente nella catena di approvvigionamento npm.

Persistenza e dead-man switch: perché la rimozione non basta

La persistenza del malware supera l'ambiente Node.js. CybersecurityNews ha documentato artefatti su più piattaforme: il servizio kitty-monitor.service su Linux, il plist com.user.kitty-monitor su macOS, un hook SessionStart in Claude Code e un trigger tasks.json in VS Code attivato all'apertura della cartella. Inoltre, un componente gh-token-monitor funge da dead-man switch: se i token vengono revocati prima della rimozione completa della persistenza, si attiva una routine potenzialmente distruttiva.

Socket ha esplicitamente avvertito che "disinstallare il pacchetto npm o cancellare node_modules non deve essere considerato cleanup sufficiente". La combinazione di esecuzione in background e meccanismi di persistenza negli strumenti dello sviluppatore richiede una rimozione attiva e verificata di ciascun artefatto.

Cosa fare adesso

Per le organizzazioni che hanno installato pacchetti @redhat-cloud-services dal 29 maggio 2026:

Isolare immediatamente le macchine e i runner CI/CD che hanno eseguito npm install con pacchetti del namespace compromesso, trattandoli come pienamente violati fino a verifica forense.
Ruotare tutte le credenziali potenzialmente esposte — cloud, registry, SSH, GPG, API token — assumendo che siano state sottratte, indipendentemente dalla presenza di anomalie nei log.
Verificare la presenza dei artefatti di persistenza documentati — servizi systemd, plist macOS, hook Claude Code, tasks.json VS Code — e rimuoverli prima di revocare i token npm, per evitare l'attivazione del dead-man switch.
Rivedere le configurazioni OIDC trusted publishing: l'incidente dimostra che la breve durata dei token non elimina il rischio se l'account che li richiede è compromesso, richiedendo controlli aggiuntivi sui commit orfani e sulla segregazione dei permessi di pubblicazione.

L'effetto Mini Shai-Hulud: quando il codice sorgente del malware è pubblico

Il TeamPCP ha rilasciato in open source il codice di Mini Shai-Hulud nel maggio 2026. Questa decisione complica l'attribuzione: non emergono sovrapposizioni infrastrutturali che colleghino l'operatore di Miasma al gruppo originale allo stato attuale. Ciò che è certo è che il rilascio pubblico abbassa la soglia per attacchi copycat contro qualsiasi organizzazione con workflow di pubblicazione npm. Il dossier non specifica il vettore di compromesso iniziale dell'account dipendente Red Hat, lasciando un punto di incertezza critico sulla catena completa dell'attacco.

Il paradosso centrale resta l'OIDC trusted publishing. Progettato per eliminare i token a lunga scadenza, ha generato token a breve scadenza che — nel contesto di un account compromesso — si sono rivelati altrettanto efficaci per contaminare la catena di approvvigionamento. La lezione non è che il meccanismo sia crittograficamente fallato, ma che la "fiducia" implicita nel CI/CD supera la durata del token: se il pipeline è violato, anche i token più effimeri diventano vettori di compromesso totale.

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