Attacco alla catena di approvvigionamento TanStack NPM: Analisi approfondita della compromissione

Postmortem: la compromissione della catena di approvvigionamento TanStack NPM espone le vulnerabilità CI/CD

L'11 maggio 2026, l'ecosistema popolare di librerie JavaScript TanStack è diventato l'ultima vittima di alto profilo di un attacco alla catena di approvvigionamento del software. In un'operazione eseguita con precisione, un attaccante ha pubblicato 84 versioni maligne su 42 pacchetti npm @tanstack/*. Questo incidente, rivelato in un dettagliato postmortem dal manutentore Tanner Linsley, serve come un brusco promemoria che l'infrastruttura di sviluppo moderna - costruita sull'automazione e sulla fiducia implicita - è diventata una superficie di attacco primaria.

La violazione non è stata un semplice furto di credenziali. Invece, è stato un exploit multistadio che ha concatenato tre vulnerabilità note ma pericolose: il pattern "Pwn Request" di pull_request_target, il poisoning della cache di GitHub Actions e l'estrazione di runtime della memoria di un token OIDC. Come nota Darktrace in un'analisi correlata, la compromissione della catena di approvvigionamento dovrebbe ora essere trattata come uno "scenario di violazione assunto", in particolare attraverso l'infrastruttura di build, integrazione e gestione dove un singolo punto di guasto può avere un raggio di esplosione massiccio.

La cronologia dell'attacco: una finestra di caos di sei minuti

L'attacco si è svolto in due fasi distinte: una fase di poisoning della cache il 10-11 maggio, seguita dalla detonazione e dalle pubblicazioni maligne l'11 maggio. L'attaccante ha prima creato un fork del repository TanStack/router, deliberatamente rinominato in github.com/zblgg/configuration per eludere le ricerche di fork. Un commit maligno contenente un payload JS in bundle di ~30.000 righe è stato aggiunto a questo fork.

L'11 maggio, l'attaccante ha aperto una richiesta di pull contro il repository principale TanStack/router. Ciò ha attivato i workflow di GitHub Actions configurati con pull_request_target, che vengono eseguiti nel contesto del repository *base* con permessi elevati. Un lavoro all'interno di questo workflow ha eseguito il codice controllato dall'attaccante dalla PR, che ha avvelenato una chiave di cache specifica di GitHub Actions collegata al gestore di pacchetti pnpm.

Il momento critico è arrivato più tardi quel giorno. Quando un manutentore legittimo ha unito una correzione non correlata, ciò ha attivato il workflow di rilascio del repository. Questo workflow ha ripristinato la cache ora avvelenata. I binari maligni, ora sul runner, hanno eseguito una tecnica di estrazione della memoria per rubare un token OIDC coniato per la pubblicazione npm. Poi hanno utilizzato questo token per pubblicare direttamente 84 versioni maligne di pacchetti nel registro npm, aggirando completamente la fase di pubblicazione prevista.

Analisi tecnica: come ha funzionato la catena di attacco

La causa principale è stata una catena di tre vulnerabilità, ognuna delle quali ha colmato un confine di fiducia che le altre assumevano.

1. Il pattern "Pwn Request": Il workflow bundle-size.yml ha utilizzato pull_request_target per eseguire benchmark sulle PR di fork. Sebbene l'autore del workflow abbia tentato una divisione di fiducia, il lavoro ha comunque verificato ed eseguito codice dal fork non attendibile, fornendo il punto di appoggio iniziale per l'esecuzione del codice.

2. Poisoning della cache di GitHub Actions: Il codice maligno è stato progettato per scrivere dati avvelenati nella directory di archiviazione pnpm sotto una chiave di cache che il workflow di rilascio legittimo avrebbe successivamente ripristinato. Ciò ha sfruttato un problema di progettazione noto in GitHub Actions, documentato dal ricercatore Adnan Khan nel 2024, dove le cache sono condivise attraverso confini di fiducia.

3. Estrazione di token OIDC: Con l'esecuzione del codice sul runner di rilascio, il malware ha scaricato la memoria del processo di lavoro di GitHub Actions per estrarre un token OIDC appena coniato. Questo token, concesso tramite il permesso id-token: write del workflow per la pubblicazione attendibile npm, è stato poi utilizzato per autenticare le pubblicazioni dirette a registry.npmjs.org. Gli attaccanti hanno riutilizzato uno script Python verbatim dalla compromissione di tj-actions/changed-files del marzo 2025.

Capacità e impatto del malware

Il payload, un file offuscato di ~2,3 MB denominato router_init.js, è stato progettato per un impatto massimo. Quando eseguito durante un npm install, avrebbe:

• Raccolto credenziali da una vasta gamma di posizioni comuni: AWS IMDS, metadati GCP, account di servizio Kubernetes, token Vault, ~/.npmrc, token GitHub e chiavi private SSH.
• Esfiltrato dati sulla rete di caricamento file di Session/Oxen messenger (filev2.getsession.org).
• Auto-propagatosi enumerando altri pacchetti che la vittima gestisce e ripubblicandoli con la stessa iniezione maligna.

TanStack ha confermato che librerie popolari come @tanstack/router e @tanstack/history sono state colpite. In particolare, le famiglie @tanstack/query*, @tanstack/table* e @tanstack/form* sono state confermate pulite. I manutentori hanno deprecato tutte le 84 versioni maligne e hanno coinvolto la sicurezza npm per ritirare le tarball dal registro.

Rilevamento, risposta e contesto del settore

Il rilevamento è stato esterno e rapido. Un ricercatore esterno che lavorava con StepSecurity ha identificato la compromissione e l'ha segnalata tramite un problema GitHub entro circa 20 minuti dalle pubblicazioni maligne. Il team TanStack ha rapidamente avviato la risposta agli incidenti, rimuovendo i permessi di push del team, scansionando tutti i 295 pacchetti @tanstack/* e divulgando pubblicamente l'incidente.

Questo attacco fa parte di una tendenza preoccupante. Segue a breve la compromissione di Axios npm nel marzo 2026, dove gli attaccanti hanno dirottato l'account di un manutentore per pubblicare versioni maligne del client HTTP enormemente popolare. Come sottolinea l'analisi di Darktrace, questi non sono anomalie ma segnali di un "cambiamento strutturale nel panorama delle minacce". Gli attaccanti stanno sempre più prendendo di mira il ventre molle degli ecosistemi open-source: account di manutentore, token di repository e sistemi CI/CD automatizzati.

Altri incidenti recenti, come l'attacco alla catena di approvvigionamento di Daemon Tools Lite mirato riportato da SecurityWeek, mostrano che sia campagne a spettro ampio che altamente mirate sono attive. In quel caso, una backdoor è stata distribuita a un gruppo selezionato di sistemi in Bielorussia, Russia e Thailandia, suggerendo motivi di spionaggio o "caccia grossa".

Lezioni chiave e misure di rafforzamento

Il postmortem di TanStack è candido sulle lezioni apprese. Cosa è andata bene è stato il rilevamento esterno rapido e la coordinazione efficace dei manutentori. Le lacune critiche includevano una mancanza di monitoraggio interno delle pubblicazioni, uso non controllato di pattern pull_request_target pericolosi e l'incapacità di annullare rapidamente le pubblicazioni dei pacchetti a causa della politica di npm per i pacchetti con dipendenti.

Il team ha già implementato diverse misure di rafforzamento:

• Eliminazione di tutte le voci di cache per i repository TanStack.
• Ristrutturazione del workflow vulnerabile bundle-size.yml e aggiunta di guardie repository_owner.
• Blocco di tutti i riferimenti di GitHub Action di terze parti a hash SHA completi anziché tag flottanti.

Per la comunità più ampia, questo incidente rafforza diverse pratiche di sicurezza critiche:

• Evitare pull_request_target a meno che non sia assolutamente necessario, e non usarlo mai per eseguire build da codice di fork.
• Controllare l'utilizzo della cache di GitHub Actions e implementare mitigazioni come la segmentazione dell'ambito di cache o l'evitamento di cache su lavori non attendibili.
• Trattare i token OIDC con estrema cura. La capacità di coniare un token pubblicabile da qualsiasi percorso di codice in un workflow è un rischio significativo.
• Implementare il monitoraggio per eventi di pubblicazione anomali e modifiche alle dipendenze.

Il futuro della difesa della catena di approvvigionamento

Come conclude il blog di Darktrace, "Il futuro della difesa della catena di approvvigionamento risiede nella visibilità comportamentale continua, nel rilevamento autonomo attraverso gli ambienti di sviluppo e build e nell'identificazione delle anomalie in tempo reale". La compromissione di TanStack illustra che gli attaccanti sono sofisticati, sfruttando la ricerca pubblicata e le catene di exploit note per un effetto massimo.

Per le organizzazioni che si affidano alle dipendenze open-source, questo incidente è un appello all'azione. Non è più sufficiente fidarsi implicitamente dell'integrità dei registri dei pacchetti. I team di sicurezza devono presumere che la compromissione avverrà all'interno degli strati software e di automazione attendibili. Le strategie difensive devono evolversi per includere un'analisi robusta della distinta base del software (SBOM), il monitoraggio comportamentale delle pipeline di build e la capacità di rispondere istantaneamente quando una dipendenza critica viene segnalata come maligna. L'era della fiducia implicita nella catena di approvvigionamento del software è finita.