Mini Shai-Hulud: 84 versioni npm di TanStack con SLSA valido

L'11 maggio 2026 TeamPCP ha compromesso la CI/CD di TanStack: 84 versioni npm con SLSA Build Level 3 valide, worm e wiper attivato dalla revoca del token.

Contenuto

Mini Shai-Hulud: 84 versioni npm di TanStack con SLSA valido
Mini Shai-Hulud: 84 versioni npm di TanStack con SLSA valido

L’11 maggio 2026, tra le 19:20 e le 19:26 UTC, il gruppo TeamPCP ha iniettato 84 versioni malevole nella pipeline CI/CD di TanStack. I pacchetti, firmati con attestazioni SLSA Build Level 3 perfettamente valide, si sono insediati in una delle librerie frontend più scaricate al mondo. Il payload non si limita a rubare credenziali: se il proprietario revoca il token GitHub, un wiper locale tenta la cancellazione dei dati, trasformando la risposta all’incidente in una trappola mortale.

Punti chiave
  • L'attacco ha sfruttato una catena di tre abusi su GitHub Actions: pull_request_target, cache poisoning ed estrazione runtime di un token OIDC dalla memoria del runner tramite /proc/<pid>/mem, senza furto di credenziali npm.
  • Le versioni malevole recano attestazioni SLSA Build Level 3 valide rilasciate da Sigstore, che certificano la pipeline compromessa come legittima e ingannano sia gli strumenti automatici che gli sviluppatori.
  • Il payload agisce da worm auto-propagante: sfrutta il trusted publishing per generare nuovi pacchetti compromessi e installa il demone gh-token-monitor, che esegue rm -rf ~/ se rileva la revoca del token con errore 40X.
  • TanStack ha dichiarato che nessun token npm è stato rubato e che il workflow di pubblicazione non è stato compromesso direttamente; l'impatto potenziale resta enorme, con oltre 12 milioni di download settimanali stimati per @tanstack/react-router e 169 nomi pacchetto identificati con 373 entry versione malevola su npm.

Come è caduta la CI/CD di TanStack: la catena di tre abusi su GitHub Actions

Il punto di ingresso è stato un fork denominato zblgg/configuration e una pull request, la #7378, contro il repository TanStack/router. Snyk ricostruisce che il flusso ha sfruttato la modalità pull_request_target, tipicamente usata per eseguire workflow su codice esterno con privilegi elevati. Da qui è scattato il cache poisoning: i aggressori hanno inquinato la cache condivisa del runner pnpm per iniettare codice malevolo nel processo di build legittimo.

Il passaggio decisivo è stato l’estrazione runtime del token OIDC dalla memoria del runner GitHub Actions. Analizzando /proc/<pid>/mem, il payload ha catturato il token di identità federata prima che il workflow legittimo terminasse. Con quel token ha pubblicato direttamente su npm le 84 versioni compromesse, bypassando completamente la necessità di rubare credenziali npm tradizionali. TanStack ha confermato che il workflow npm publish non è stato violato e che nessun token npm è stato sottratto.

Perché le attestazioni SLSA Build Level 3 hanno firmato malware

Le versioni malevole non sono contraffazioni: recano attestazioni SLSA Build Level 3 verificate da Sigstore, il che le rende indistinguibili dalle release genuine per qualsiasi strumento di scansione automatica. Il problema è architetturale: SLSA attesta quale pipeline ha prodotto l’artefatto, non se quel comportamento fosse legittimo.

"SLSA provenance confirms which pipeline produced the artifact, not whether the pipeline was behaving as intended"
— StepSecurity

In altre parole, il sistema di provenance ha funzionato esattamente come previsto, certificando un processo di build che era stato dirottato dall’interno. Per gli sviluppatori che avevano integrato le attestazioni come proxy di fiducia, l’incidente rappresenta un fallimento del modello di threat model: la pipeline era compromessa, ma la firma digitale gridava sicurezza.

Worm auto-propagante e wiper attivato dalla difesa

All’interno dei tarball, Wiz e Snyk hanno isolato il file obfuscato router_init.js, di circa 2,3 MB, e un optionalDependency che sfrutta l’hook prepare per eseguire il payload tramite Bun. Il codice ruba credenziali e, sfruttando il meccanismo di trusted publishing, si replica autonomamente pubblicando ulteriori pacchetti compromessi. È questa la natura di worm del Mini Shai-Hulud: non attende comandi esterni, ma usa i token delle vittime per propagarsi.

La componente più insidiosa è il demone gh-token-monitor, documentato da Wiz. Ogni 60 secondi interroga le API GitHub; al rilevamento di un errore 40X, sintomo di revoca del token, tenta l’esecuzione di rm -rf ~/, cancellando i dati locali della macchina infetta. Il demone si arresta automaticamente dopo 24 ore, ma in quella finestra la difesa standard diventa innesco della distruzione. Non è confermato che il wiper abbia causato danni reali, ma la capacità è presente e operativa.

Esfiltrazione su tre canali e l'attribuzione a TeamPCP

I dati rubati escono attraverso una rete ridondante di tre canali paralleli. Il primo è il dominio typosquat git-tanstack[.]com, registrato per confondere il traffico legittimo. Il secondo sfrutta la rete Session Protocol. Il terzo funziona da dead drop su GitHub API, utilizzando il repository intitolato ‘Shai-Hulud: Here We Go Again’. Wiz attribuisce l’intera operazione al gruppo TeamPCP con alta confidenza.

L’incidente è tracciato come CVE-2026-45321, con punteggio CVSS 9,6 su 10. Il numero di ambienti effettivamente compromessi non è ancora quantificato, né è verificato se il worm abbia attivamente propagato verso altri maintainer oltre a quelli identificati. Il dato certo resta l’esposizione: oltre 12 milioni di download settimanali stimati per @tanstack/react-router e un ecosistema npm che ha ingestito 169 nomi pacchetto con 373 entry versione malevola.

Cosa fare adesso

  • Ispezionare le installazioni: verificare la presenza di pacchetti @tanstack aggiornati l’11 maggio 2026 tra le 19:20 e le 19:26 UTC, confrontando le versioni con le 373 entry malevole documentate da Aikido su npm. Rimediare prima di revocare qualsiasi token.
  • Non revocare token su macchine live: isolare i sistemi sospetti dalla rete prima di disattivare i token GitHub, per evitare il trigger del wiper gh-token-monitor e la conseguente esecuzione di rm -rf ~/.
  • Rivedere i workflow GitHub Actions: eliminare l’uso non necessario di pull_request_target e cache condivise tra job sospetti; limitare i permessi OIDC dei runner al minimo indispensabile e monitorare gli accessi a /proc/*/mem.
  • Decouplare fiducia e provenance: trattare le attestazioni SLSA come verifica di pipeline e non come garanzia di integrità del codice sorgente; implementare pin dei pacchetti tramite hash e audit indipendente del codice prima dell’installazione.

L’incidente TanStack non è un semplice furto di credenziali, ma una dimostrazione concreta di come la difesa in profondità possa essere riconvertita in arma contro chi la applica. La revoca di un token, istinto automatico di ogni team di risposta, qui diventa detonatore. Per le aziende che si affidavano alle attestazioni SLSA come scorciatoia di fiducia, il messaggio è chiaro: la pipeline è solo processo, mai sostituto del controllo umano sul codice.

Domande frequenti

L'attacco ha compromesso direttamente npm o GitHub?

No. I server di npm e GitHub non sono stati violati. Gli aggressori hanno abusato di funzioni legittime come pull_request_target, il caching dei runner e il trusted publishing OIDC, dirottando la pipeline senza infrangere la perimetrale dei servizi.

Perché le attestazioni SLSA erano valide se il codice era malevolo?

Le attestazioni SLSA Build Level 3 verificate da Sigstore certificano quale pipeline ha generato l’artefatto, non se il codice sorgente inserito in quella pipeline fosse benigno. Poiché il build runner era compromesso, la firma era corretta ma il contenuto era tossico.

Cosa rischia chi revoca il token GitHub su una macchina infetta?

Il demone gh-token-monitor rileva l’errore 40X come segnale di revoca e tenta l’esecuzione di rm -rf ~/, cancellando i dati locali. Per questo il primo passo non deve essere la revoca, ma l’isolamento della macchina.

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

Fonti

Link utili

Apri l'articolo su DeafNews