L'11 maggio 2026, alle 19:20 UTC, qualcuno ha pubblicato @tanstack/react-router versione compromessa. Non un attaccante con credenziali rubate. La pipeline di rilascio ufficiale di TanStack, con la sua identità OIDC verificata, ha firmato un pacchetto malevolo con una provenance SLSA Build Level 3 perfettamente valida.
Dodici milioni di download settimanali. Un certificato Sigstore che dice "questo binario viene davvero da quella repo". Tutto vero. Tutto autentico. Tutto compromesso.
Si chiama Mini Shai-Hulud, è la quarta ondata di una campagna che TeamPCP porta avanti dal 2025, e il nome viene da Dune. I worm giganti che attraversano il deserto e divorano tutto. La metafora è precisa fino al disagio.
Come si compromette una pipeline senza rubare niente
L'attacco a TanStack è una catena di tre vulnerabilità, nessuna delle quali da sola sarebbe bastata.
Prima, un fork camuffato (zblgg/configuration, rinominato per sfuggire alle ricerche fork-list). Poi una pull request che attiva un workflow pull_request_target, il trigger di GitHub Actions che esegue il codice del fork dell'attaccante invece di quello della repo madre. Quel codice avvelena la cache pnpm di GitHub Actions.
Quando il maintainer legittimo, ore o giorni dopo, fa il merge di una sua PR su main, il workflow di release ripristina la cache avvelenata e costruisce il pacchetto. A quel punto il binario dell'attaccante legge l'OIDC token direttamente dalla memoria del runner, da /proc/<pid>/mem, e pubblica il pacchetto malevolo con la firma crittografica della pipeline ufficiale.
Nessun token npm rubato. Nessun account compromesso. La 2FA non sarebbe servita a niente, perché chi ha pubblicato il pacchetto era, in senso tecnico, la pipeline ufficiale del progetto.
Snyk lo ha registrato come CVE-2026-45321, CVSS 9.6. Quarantadue pacchetti TanStack, ottantaquattro versioni. Poi il worm si è auto-propagato. Mistral AI. UiPath. Guardrails AI. OpenSearch. A fine giornata Snyk contava 170 pacchetti compromessi, 518 milioni di download cumulativi.
Il dead man's switch
La parte che fa più impressione non è la sofisticazione del vettore. È quello che il payload fa una volta dentro.
Il malware installa hook di persistenza dentro Claude Code (~/.claude/setup.mjs, ~/.claude/router_runtime.js) e VS Code. Esfiltra credenziali attraverso la rete Session, un messenger decentralizzato e crittografato end-to-end, perché non c'è più un C2 da bloccare.
E poi, per impedire la rotazione dei token, piazza un dead man's switch: un servizio (systemd su Linux, LaunchAgent su macOS) che ogni sessanta secondi chiama api.github.com/user con il token rubato. Se il token viene revocato e GitHub risponde 40x, il servizio esegue rm -rf ~/. Wipe della home directory. TTL di 24 ore.
Prima di revocare un token compromesso, devi disinnescare il trigger. Cercare ~/.local/bin/gh-token-monitor.sh, ~/.config/gh-token-monitor/, il LaunchAgent. Se sbagli ordine, perdi i file.
C'è anche una clausola geopolitica nel codice. Se il sistema è configurato in russo, il malware termina senza esfiltrare niente. Se il sistema sembra essere in Israele o Iran, c'è una branch con probabilità 1 su 6 di eseguire rm -rf /. Microsoft lo ha documentato analizzando il pacchetto Mistral su PyPI. Un malware con opinioni geopolitiche.
Quello che è cambiato davvero
Negli ultimi quindici anni la difesa del software open source si è costruita attorno a un'idea: firmare crittograficamente i binari così sappiamo da dove vengono. Sigstore, SLSA, le attestazioni di provenance, npm trusted publishing. Tutto questo lavoro ha un presupposto implicito: se la pipeline è autentica, il codice è affidabile.
Mini Shai-Hulud è il primo caso documentato in cui questa equivalenza si rompe in modo pulito e ripetibile. Il pacchetto è stato firmato dalla pipeline giusta. La pipeline ha eseguito il codice sbagliato. Il certificato è valido. Il malware è dentro.
La firma crittografica non garantisce più che il codice sia pulito. Garantisce solo che è stato compilato dalla pipeline giusta. Sono cose diverse.
Non è un problema tecnico isolato, è un problema di modello mentale. Continueremo a fidarci della provenance perché è meglio dell'assenza di provenance, ma il vecchio sillogismo (pacchetto firmato uguale pacchetto sicuro) è morto l'11 maggio alle 19:20 UTC.
Cosa fare lunedì mattina
Per chi gestisce repository Node, la procedura minima è cambiata. npm install standard non basta più, perché esegue gli script preinstall e postinstall automaticamente. Il pattern di base diventa npm ci --ignore-scripts, seguito da npm audit --audit-level=moderate e npm audit signatures. Lo --ignore-scripts è il punto critico. Disabilita l'esecuzione automatica degli hook del ciclo di vita, che è esattamente il vettore di Mini Shai-Hulud.
Poi va fatto il grep su pattern noti: setup.mjs, bun_environment.js, riferimenti a SHA1HULUD, shai-hulud, stringhe come OhNoWhatsGoingOnWithGitHub nei commit. Controllare se esiste un workflow discussion.yaml o shai-hulud-workflow.yml mai aggiunto da nessuno del team. Cercare runner self-hosted registrati con il nome SHA1HULUD.
Su GitHub abilitare Dependabot alerts, security updates, malware alerts, secret scanning e push protection. Su npm passare al trusted publishing invece dei token, e usare WebAuthn al posto di TOTP per la 2FA.
Se trovi qualcosa, non fare npm install. Disinnesca il dead man's switch, poi isola la macchina, poi ruota i token, in quest'ordine.
Le checklist non sono nuove. La consapevolezza che devi eseguirle anche sui pacchetti firmati, quella sì.
Perché questo riguarda chi non scrive codice
Ogni applicazione SaaS che usi è costruita su una catena di dipendenze open source. TanStack è una delle librerie più usate nell'ecosistema React. Mistral AI è il modello su cui qualcuno ha basato il proprio chatbot interno. Guardrails AI è il livello di sicurezza che dovrebbe impedire ai modelli di sbagliare. Tutti compromessi, tutti firmati, tutti distribuiti dalla loro pipeline ufficiale.
Quando si parla di "supply chain attack" sembra un problema da specialisti. È invece il problema strutturale di un'economia digitale che ha esternalizzato la fiducia al codice di sconosciuti, e poi ha esternalizzato la verifica di quel codice a certificati crittografici, e adesso scopre che i certificati certificano la cosa sbagliata.
Frank Herbert l'aveva scritto. Il deserto è grande, il verme è invisibile finché non è troppo tardi, e il segreto per attraversarlo è non camminare in un ritmo regolare. La pipeline di rilascio del software open source è il ritmo regolare. TeamPCP è il verme. La spezia, come al solito, deve scorrere.