Miasma: il malware aveva un certificato di provenienza valido

Il malware pubblicato su npm il 1° giugno 2026 portava una attestazione di provenienza SLSA valida. Non falsificata, non aggirata: valida. Firmata correttamente, verificabile, riconducibile a una build reale eseguita su un'infrastruttura reale. Chiunque avesse controllato la provenienza — cioè la cosa giusta da fare, quella che l'industria ha passato cinque anni a costruire — avrebbe visto un pacchetto in regola.

Questo è il punto del caso Miasma, ed è la distinzione meno capita di tutta la supply chain security: SLSA attesta DOVE un artefatto è stato costruito, non SE l'input della build era legittimo.

1. 1° giugno 2026, ~10:53–13:46 UTC
   I commit malevoli

   compaiono sull'organizzazione GitHub RedHatInsights.

2. 1° giugno 2026, ~13:00 UTC
   La revoca

   npm rimuove la maggior parte delle versioni malevole.

3. 1° giugno 2026, 18:50 UTC
   Il bollettino

   Red Hat pubblica RHSB-2026-006, in parallelo alla disclosure di Wiz Research.

4. 4 giugno 2026
   La seconda ondata

   Wiz documenta una tecnica diversa basata su binding.gyp.

L'origine

Il bersaglio è il namespace @redhat-cloud-services: librerie frontend usate per la Hybrid Cloud Console. Secondo Wiz, almeno 32 pacchetti e oltre 90 versioni malevole, con un volume aggregato di circa 80.000 download a settimana. Nessuna CVE: anche qui è la distribuzione ad essere compromessa, non un prodotto. Il riferimento è il bollettino RHSB-2026-006, ancora in stato Ongoing.

La cronologia è compressa. 1° giugno 2026, tra le ~10:53 e le ~13:46 UTC: i commit malevoli compaiono sull'organizzazione GitHub RedHatInsights. Verso le 13:00 UTC npm revoca la maggior parte delle versioni. Alle 18:50 UTC Red Hat pubblica il bollettino, in parallelo alla disclosure di Wiz Research. Il 4 giugno Wiz documenta una seconda ondata, con una tecnica diversa basata su binding.gyp.

Red Hat è netta sul perimetro, e va riportato con precisione: i servizi cloud gestiti non sono coinvolti (ARO, OSD, ROSA), nessuna build di prodotto ha incluso le versioni compromesse, e nessuna azione è richiesta ai clienti. Non è un incidente sui prodotti Red Hat. È un incidente su pacchetti npm pubblicati da Red Hat — differenza sostanziale, spesso persa nei titoli.

Il punto di ingresso è l'account GitHub di un dipendente (T1078). Come sia stato compromesso non è stato confermato pubblicamente, ed è un vuoto che va dichiarato, non riempito con ipotesi.

La catena d'attacco

Il meccanismo è elegante nel modo peggiore.

L'attore non prova a superare la code review: la gira intorno. Spinge commit "orfani" su branch temporanei — codice che vive nel repository senza passare da una pull request, senza un approvatore, senza un reviewer che possa dire di no.

Quei commit introducono un workflow GitHub Actions minimale che richiede un token OIDC (id-token: write) e pubblica su npm. Ed è qui che accade la cosa importante: la build è autentica. Gira davvero sull'infrastruttura GitHub Actions dell'organizzazione RedHatInsights. Il token OIDC è emesso legittimamente a quel workflow (T1550.001). npm riceve un pacchetto costruito esattamente dove ci si aspetta che venga costruito, da una CI che ha diritto di pubblicare, e gli assegna attestazioni di provenienza SLSA valide (T1195.001).

La catena di fiducia ha funzionato come progettato. Ha semplicemente certificato con precisione notarile un input avvelenato.

Il payload sta in un preinstall che carica index.js, pesantemente offuscato con eval() e codifica di tipo ROT (T1027). Una volta eseguito, va a caccia di credenziali cloud — con enfasi sulle identità GCP e Azure (T1526) — e di secret CI/CD dai file dell'ambiente (T1552.001).

Una divergenza da dichiarare: i report di Wiz e StepSecurity non concordano su livello di offuscamento e capacità effettive del payload. Le specifiche fini sono in evoluzione. La meccanica di pubblicazione è solida; il dettaglio del malware, meno.

Il malware riciclato

Il codice non è nuovo. Deriva dalla famiglia (Mini) Shai-Hulud, resa open source dal gruppo TeamPCP. Un secondo attore l'ha ripreso e riconfezionato cambiando solo il vestito: via i riferimenti a Dune, dentro la mitologia greca, repository intitolato "Miasma: The Spreading Blight".

È un cambiamento di regime, non un dettaglio di colore. Un toolkit di supply chain che diventa pubblico smette di essere firma di un gruppo e diventa commodity. Chiunque può forkarlo, ritematizzarlo, rilanciarlo. E l'attribuzione basata sulla somiglianza del codice — per anni il pane degli analisti — smette di funzionare: due campioni identici possono appartenere ad attori che non si sono mai parlati.

Detection

• Descrizione del repository: Miasma: The Spreading Blight
• User-agent nelle query GCP: google-api-nodejs-client/7.0.0 gl-node/20.11.0 gccl/7.0.0
• Commit orfani su branch temporanei nelle vostre org GitHub: nessuna PR, nessun reviewer, workflow nuovo
• Workflow che chiedono id-token: write e pubblicano su npm senza essere passati da una review
• Elenco completo delle 32+ versioni malevole: pubblicato da Wiz e Red Hat — usate quello, non una regex sul nome

Non cercate un pacchetto "non firmato": non lo troverete. Cercate chi ha autorizzato l'input della build.

Rimedi

Le versioni malevole sono già state revocate da npm. Restano le conseguenze:

• Audit delle workstation degli sviluppatori, delle pipeline CI/CD e dei repository per la finestra del 1° giugno
• Rotazione precauzionale: token GitHub, chiavi SSH, credenziali cloud, secret CI/CD. Precauzionale significa anche senza prova di accesso
• SBOM e package allowlisting per sapere cosa entra davvero nelle build
• Monitoraggio delle pipeline: un workflow nuovo che chiede id-token: write è un evento di sicurezza, non un dettaglio DevOps
• Bloccare la possibilità di eseguire workflow da commit non revisionati

Cosa insegna

Abbiamo costruito la provenienza crittografica per rispondere alla domanda "questo pacchetto viene da dove dice?". Miasma dimostra che è la domanda sbagliata — o meglio, che è solo metà della domanda. La risposta era sì, ed era vera, e il pacchetto era comunque malevolo.

La provenienza è una catena di custodia, non un giudizio di merito. Certifica il percorso, non il contenuto. Se un attaccante riesce a inserire codice prima del punto in cui la catena inizia — un commit orfano, un workflow non revisionato — allora tutta la macchina di attestazione lavora per lui, e gli firma il malware con la vostra reputazione.

La lezione operativa è meno romantica di SLSA: la sicurezza della build si decide nel controllo di accesso al repository, non nella firma finale.