Worm Mini Shai-Hulud: 169 pacchetti npm/PyPI con SLSA valida

169 pacchetti npm e PyPI compromessi da worm Mini Shai-Hulud con SLSA valida. L'attacco abusa OIDC trusted publishing per diffondersi nelle pipeline CI/CD.

Contenuto

Worm Mini Shai-Hulud: 169 pacchetti npm/PyPI con SLSA valida
Worm Mini Shai-Hulud: 169 pacchetti npm/PyPI con SLSA valida

Il 11 maggio 2026 il gruppo TeamPCP ha lanciato una campagna coordinata contro gli ecosistemi npm e PyPI, compromettendo oltre 160 pacchetti open source tra cui TanStack, Mistral AI e UiPath. I payload si propagano come worm attraverso pipeline CI/CD violate, sfruttando il trusted publishing OIDC di GitHub Actions per pubblicare versioni malevole con attestati di provenance SLSA Build Level 3 validi. Il paradosso è che il sistema stesso di verifica della supply chain diventa il camuffamento perfetto: le difese standard non rilevano anomalie perché i pacchetti provengono da workflow legittimi e firmati.

«In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces validly attested malicious packages.»
— Ashish Kurmi, StepSecurity
Punti chiave
  • TeamPCP ha compromesso oltre 160 nomi di pacchetto tra npm e PyPI, con quasi 370 versioni malevole rilevate da Aikido.
  • L'attacco sfrutta GitHub Actions OIDC trusted publishing, estraendo token dalla memoria del runner tramite cache poisoning di pnpm.
  • I pacchetti malevoli dispongono di provenance SLSA Build Level 3 valida, essendo stati pubblicati attraverso la pipeline legittima dei progetti.
  • Il payload include un dead-man's switch che esegue un wiper locale se il token npm generato viene revocato, con polling ogni 60 secondi.

Come funziona il worm: dal fork alla cache avvelenata

Il vettore iniziale sfrutta la combinazione tra fork di repository e workflow GitHub Actions configurati con pull_request_target. L'attaccante crea un fork rinominato, inserisce un commit orfano che modifica la cache pnpm e innesca l'esecuzione del workflow sulla superficie legittima del progetto. Da qui il codice malevolo estrae i token OIDC direttamente dalla memoria del runner, leggendo /proc/<pid>/mem, ottenendo così le credenziali necessarie per pubblicare pacchetti attraverso il trusted publishing.

Secondo Peyton Kennedy di Endor Labs, «The orphaned commit additionally triggered a GitHub Actions workflow run against the legitimate TanStack/router workflow surface». Una volta ottenuto l'accesso, il worm scambia il token OIDC con un token di pubblicazione npm, abilitando bypass_2fa, e enumera tutti i pacchetti associati al maintainer per auto-propagarsi. L'infezione si diffonde quindi senza rubare token a lunga durata, ma abusando il meccanismo di federazione delle identità tra GitHub e il registry.

All'interno dei tarball npm compromessi, Wiz ha identificato un file JavaScript offuscato di circa 2,3 MB denominato router_init.js. Il payload profila l'ambiente target ed esegue un credential stealer multiplo in grado di rubare token CI/CD da GitHub Actions, GitLab e CircleCI, oltre a credenziali cloud AWS IMDSv2, GCP, Azure, account Kubernetes, token HashiCorp Vault e secret di registro.

Per garantire persistenza, il malware installa un servizio denominato gh-token-monitor su macOS attraverso un LaunchAgent e su Linux tramite systemd. Questo meccanismo assicura che il credential stealer continui a operare anche dopo il riavvio del sistema, mantenendo attiva la raccolta di token e la connessione con l'infrastruttura di comando e controllo.

Session Protocol e geofencing: le due facce del payload

L'esfiltrazione dei dati non si appoggia a server centralizzati facilmente sequestrabili, ma al Session Protocol, una rete peer-to-peer resistente al takedown. I dati rubati transitano attraverso il dominio filev2.getsession[.]org, repository GitHub controllati dall'attaccante e il dominio api.masscan[.]cloud. L'uso di Session rende complessa l'interruzione delle comunicazioni senza un'azione coordinata su nodi distribuiti geograficamente.

Sull'ecosistema PyPI, i pacchetti associati a mistralai e guardrails-ai scaricano un payload aggiuntivo dall'indirizzo git-tanstack[.]com/tmp/transformers.pyz. Il codice si attiva solo su sistemi Linux, evita deliberatamente ambienti configurati in lingua russa e include un ramo distruttivo geofenced per Israele e Iran. In queste aree, il payload esegue rm -rf / con probabilità di 1 su 6, trasformando l'infostealer in un potenziale wiper.

Nel dettaglio, il pacchetto guardrails-ai nella versione 0.10.1 esegue il codice malevolo direttamente all'atto dell'importazione Python, scrivendo il file /tmp/transformers.pyz. Questo comportamento conferma che il pericolo non è limitato alla fase di installazione, ma si attiva nel momento in cui la libreria viene caricata nell'ambiente di esecuzione, rendendo più ampio il superficie d'attacco.

Il paradosso della provenance: quando SLSA Level 3 nasconde il malware

Il tratto distintivo della campagna Mini Shai-Hulud è che i pacchetti compromessi dispongono di attestati di provenance SLSA Build Level 3 perfettamente validi. Poiché il malware è stato pubblicato attraverso la pipeline di rilascio legittima dei progetti, le firme crittografiche e i log di audit non mostrano anomalie: il sistema di fiducia continua a funzionare tecnicamente, anche se il workflow sottostante è stato compromesso.

Ashish Kurmi di StepSecurity ha definito l'evento come «the first documented npm worm that produces validly attested malicious packages», sottolineando che «the attack published malicious versions through the project's own GitHub Actions release pipeline using hijacked OIDC tokens». La validità formale della provenance diventa così un'arma a doppio taglio: rassicura chi scarica, nascondendo il payload sotto uno strato di conformità.

Avital Harel di Upwind ha inquadrato la campagna in una «broader shift in supply chain attacks from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure». Secondo Raphael Silva di Aikido Security, «The important part is not only the number of packages, but where they run. These packages are likely to be installed in local developer environments, CI jobs, release workflows, and internal build systems». L'impatto si moltiplica perché il codice malevolo si insinua nei nodi più sensibili della catena produttiva.

Aikido ha rilevato quasi 370 versioni malevole distribuite su oltre 160 nomi di pacchetto, mentre i download cumulativi stimati per i pacchetti coinvolti superano i 518 milioni. TanStack ha subito direttamente l'impatto di oltre 40 pacchetti e oltre 80 versioni, con il solo @tanstack/react-router che registra quasi 12 milioni di download settimanali. Sul fronte PyPI, il pacchetto mistralai ha accumulato circa 86mila download negli ultimi sette giorni prima della messa in quarantena.

Cosa fare adesso

  • Verificare la provenienza del codice all'interno dei workflow attendibili: i team DevOps devono auditare ogni step della pipeline CI/CD, inclusi i pacchetti caricati nella cache pnpm, e non fidarsi ciecamente degli attestati SLSA se il runner è stato compromesso.
  • Isolare gli ambienti di build e limitare la durata dei token OIDC: i runner GitHub Actions devono operare in sandbox con memoria protetta, accesso minimo ai processi e token con scadenza breve, riducendo la finestra per l'estrazione da /proc.
  • Monitorare i lifecycle scripts e le importazioni di librerie: gli strumenti di sicurezza devono tracciare l'esecuzione di codice all'atto dell'importazione, non solo durante npm install, perché payload come guardrails-ai si attivano al caricamento del modulo.
  • Non revocare i token senza isolare prima il sistema: il dead-man's switch controlla la revoca ogni 60 secondi e scatena rm -rf ~/. Prima di disattivare le credenziali è necessario isolare la macchina e rimuovere la persistenza macOS LaunchAgent o Linux systemd.

Mini Shai-Hulud non è un semplice furto di credenziali, ma la dimostrazione che la supply chain moderna ha spostato il confine del rischio dalle vulnerabilità del codice alle identità che lo compilano. Finché la risposta alla compromissione sarà la revoca di token, e non la verifica del comportamento interno alle pipeline, gli attaccanti continueranno a usare la stessa architettura di fiducia contro chi la difende. La sicurezza deve imparare a diffidare anche dei propri workflow.

Cosa cambia per chi usa npm e PyPI

Come può un pacchetto avere provenance SLSA valida se contiene malware?

La provenance SLSA Build Level 3 attesta che il pacchetto è stato generato da una pipeline specifica e che il sorgente corrisponde a un commit noto. Se l'attaccante compromette il workflow CI/CD legittimo, il pacchetto malevolo esce dalla stessa pipeline, con gli stessi attestati. La firma è tecnicamente corretta, ma il processo sottostante è stato violato.

Il dead-man's switch è già stato attivato su sistemi reali?

Non ci sono evidenze pubbliche che il meccanismo di distruzione automatica abbia causato danni concreti. Tuttavia, Wiz e The Hacker News confermano che lo script è attivo nel payload e che esegue il wipe se il token creato dal malware viene revocato, rendendo pericolosa qualsiasi reazione immediata senza isolamento.

L'attacco ha compromesso i server centrali di npm o PyPI?

No. La campagna ha colpito singoli maintainer e i loro workflow GitHub Actions, non le infrastrutture dei registry. npm ha rimosso le versioni malevole e PyPI ha messo in quarantena i pacchetti compromessi, ma i server centrali non sono stati violati.

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

Fonti

Link utili

Apri l'articolo su DeafNews