npm, PyPI e Mini Shai-Hulud: la settimana in cui la supply chain è tornata al centro della cybersecurity operativa
Campagna Mini Shai-Hulud su npm e PyPI: 84 versioni malevole TanStack pubblicate via GitHub Actions, abuso di token OIDC, breach OpenAI confermato. Perché la supply chain è ormai un problema di cybersecurity operativa, non solo di sviluppo — e cosa controllare oggi.
Aggiornato al 14 maggio 2026.
Questa settimana il rischio software supply chain è tornato in primo piano. Non parliamo di un singolo pacchetto sospetto caricato su npm da un account appena creato, ma di una campagna più ampia che ha colpito pacchetti legittimi, usati da sviluppatori e pipeline CI/CD reali, passando da npm a PyPI e coinvolgendo progetti conosciuti come TanStack, Mistral AI, UiPath, OpenSearch e Guardrails AI.
Il nome ricorrente nelle analisi è Mini Shai-Hulud: una campagna orientata al furto di credenziali e alla propagazione automatica attraverso gli ecosistemi di sviluppo. L'aspetto più importante, per chi gestisce infrastrutture e applicazioni, non è il nome della campagna. È il fatto che l'ambiente di build è diventato un bersaglio primario.
Cosa è successo
Il caso più documentato è quello TanStack. Secondo il postmortem ufficiale, l'11 maggio 2026, tra le 19:20 e le 19:26 UTC, sono state pubblicate 84 versioni malevole distribuite su 42 pacchetti @tanstack/*. Le versioni compromesse non sono arrivate da un classico furto di password di un maintainer: l'attacco ha sfruttato una combinazione di workflow GitHub Actions, cache poisoning e abuso di token OIDC generati durante la pipeline.
In pratica, il codice malevolo è riuscito a entrare nel percorso di rilascio abbastanza vicino al processo legittimo da ottenere pubblicazioni apparentemente affidabili. Questo è il punto che deve far riflettere: firme, attestazioni e provenienza sono strumenti utili, ma non bastano se l'ambiente che le produce è già compromesso.
Socket, StepSecurity e NHS Digital hanno poi collegato l'episodio a una campagna più ampia che include pacchetti npm e PyPI. Tra gli indicatori pubblici compaiono pacchetti legati a Mistral AI, OpenSearch e Guardrails AI, con payload capaci di eseguire codice in fase di installazione o importazione, cercare token, chiavi cloud, segreti CI/CD e tentare nuove pubblicazioni malevole quando trovano credenziali con privilegi sufficienti.
Perché è un incidente operativo, non solo tecnico
La supply chain software viene spesso trattata come un tema da sviluppo: lockfile, dipendenze, versioni, pacchetti. Questo incidente mostra invece che è anche un tema di sicurezza operativa quotidiana.
Un npm install, un pnpm install o un import Python non sono più solo operazioni di setup. In un contesto compromesso possono diventare il punto in cui vengono letti token GitHub, chiavi npm, credenziali AWS, GCP o Azure, secret manager, token Kubernetes, configurazioni locali e chiavi SSH.
Il rischio non si ferma alla macchina dello sviluppatore. Se la dipendenza viene installata in CI/CD, il payload può vedere variabili d'ambiente, token temporanei, permessi di pubblicazione e accessi ai repository. Da lì l'attacco può provare a muoversi lateralmente: pubblicare nuove versioni, alterare repository, creare persistenza o esfiltrare materiale sensibile.
L'effetto breach: il caso OpenAI
Il 13 maggio 2026 OpenAI ha pubblicato una risposta all'attacco TanStack. Secondo l'azienda, due dispositivi di dipendenti nel contesto corporate sono stati impattati. OpenAI afferma di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale, ma ha osservato attività coerenti con esfiltrazione di credenziali su un sottoinsieme limitato di repository interni accessibili dai dispositivi coinvolti.
La parte interessante dal punto di vista operativo è la risposta: isolamento dei sistemi, revoca delle sessioni, rotazione delle credenziali, restrizioni temporanee sui workflow di deploy e rotazione preventiva di certificati di firma. È il comportamento corretto quando l'incidente riguarda ambienti sviluppatore e pipeline: si presume compromissione fino a prova contraria, si riduce il raggio d'azione e si rigenerano i segreti.
Cosa controllare subito
Per chi gestisce progetti Node.js o Python, la priorità è ricostruire l'esposizione reale. Bisogna controllare i lockfile, come package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt o poetry.lock, e verificare se nei giorni 11-14 maggio sono state installate versioni collegate agli indicatori pubblici. Non basta guardare le dipendenze dirette: molti pacchetti arrivano in modo transitivo.
Vanno poi verificati i log CI/CD delle ultime esecuzioni: installazioni anomale, richiami a pacchetti inattesi, download da domini non abituali, uso improvviso di Bun dove non previsto, connessioni verso domini collegati agli IOC pubblici, modifiche o publish npm non pianificati.
Ogni runner o macchina sviluppatore che abbia installato una versione malevola va trattato come potenzialmente compromesso. In quel caso la sola reinstallazione delle dipendenze non è sufficiente: servono rotazione dei token, verifica dei repository, controllo delle chiavi SSH, revisione dei secret manager e analisi dei meccanismi di persistenza indicati dai ricercatori.
La lezione per le PMI
Per molte PMI il problema non è avere un SOC da grande azienda. Il problema è sapere, in poche ore, dove una libreria è stata installata e quali segreti erano raggiungibili da quell'ambiente.
Tre controlli semplici cambiano molto:
Inventario delle dipendenze e dei lockfile per ogni progetto attivo.
Separazione netta tra credenziali di sviluppo, CI e produzione.
Una procedura pronta per ruotare token GitHub, npm, cloud e SSH senza improvvisare.
Quando arriva una campagna come Mini Shai-Hulud, chi ha questi tre elementi non elimina il rischio, ma riduce drasticamente il tempo di risposta. E nella cybersecurity operativa il tempo è spesso la differenza tra incidente contenuto e compromissione estesa.
In sintesi
L'attacco di questa settimana non è solo "un altro malware su npm". È un promemoria: oggi il perimetro passa anche da package.json, dai runner CI, dai token OIDC, dalle cache di build e dalle macchine sviluppatore.
La difesa efficace non consiste nel bloccare ogni libreria nuova. Consiste nel costruire attrito intelligente: dipendenze bloccate, finestre di cooldown, permessi minimi, log consultabili, segreti ruotabili e workflow progettati come ambienti ostili per impostazione predefinita.
Il messaggio operativo è semplice: se una pipeline può pubblicare software o accedere a segreti, va trattata come un sistema critico. Anche quando "sta solo installando dipendenze".
> ln -s ./linked-nodes
- [PARTE DI] Cyberinfrastruttura Operativa