L'ultima campagna di attacchi alla catena di approvvigionamento non si è limitata a compromettere i registri open source. Ha dirottato la pipeline di rilascio all'interno di una delle organizzazioni più attente alla sicurezza al mondo, e il punto di ingresso è stata una normale installazione di dipendenze npm.
L'11 maggio 2026, il gruppo di hacker TeamPCP ha sferrato la quarta ondata della sua campagna basata sul worm Shai-Hulud, ora nota come Mini Shai-Hulud. L'attacco ha compromesso 84 versioni di pacchetti dannosi su 42 pacchetti TanStack nel registro npm in un arco di tempo di sei minuti, espandendosi infine a oltre 170 pacchetti nei registri del codice sorgente npm e PyPI (Python Package Index), inclusi gli spazi dei nomi appartenenti a Mistral AI, UiPath e OpenSearch. Almeno un pacchetto colpito, @tanstack/react-router, riceve circa 12 milioni di download settimanali.
Si tratta della quarta ondata di una campagna sempre più intensa. Le ondate precedenti includono la compromissione iniziale di npm (Shai-Hulud 1.0) e l'ondata 2.0 che ha preso di mira le credenziali di GitHub.
OpenAI ha reso noto questa settimana che due dispositivi di dipendenti sono stati compromessi. Non sono stati interessati dati degli utenti, sistemi di produzione o proprietà intellettuale, ma le misure di contenimento hanno richiesto l'isolamento dei sistemi, la rotazione delle credenziali, il ricorso a esperti forensi esterni e una rotazione completa dei certificati di firma del codice su macOS, Windows, iOS e Android, innescata dall'installazione di una singola dipendenza.
Mini Shai-Hulud - Quarta serie: in breve
- Data dell'attacco: 11 maggio 2026
- Pacchetti compromessi: 84 versioni dannose in 42 pacchetti @tanstack/*; oltre 170 in totale nei registri npm e PyPI
- CVE: CVE-2026-45321, punteggio CVSS 9,6 (critico)
- Attribuzione: TeamPCP (noto anche come PCPcat, UNC6780)
- Meccanismo: tre vulnerabilità concatenate in GitHub Actions – Pwn Request, cache poisoning, estrazione di token OIDC (OpenID Connect) dalla memoria del processo runner
- Vittima di rilievo: OpenAI – compromessi due dispositivi di dipendenti; segreti aziendali, tra cui certificati di firma del codice per macOS, iOS, Windows e Android, sono stati sottratti dai repository interni del codice sorgente
- Versioni precedenti: Shai-Hulud 1.0 (settembre 2025), 2.0 (novembre 2025) e 3.0 (dicembre 2025)
- Conseguenze: ambienti di sviluppo e CI/CD compromessi , account dei manutentori e pacchetti presi in ostaggio; inoltre, la provenienza SLSA e le build firmate non sono più "sicure per impostazione predefinita"
- Rischi principali: pacchetti dannosi che superano l'attestazione di provenienza SLSA (Supply-chain Levels for Software ) di livello tre
Come è avvenuto l'attacco
La quarta ondata di Mini Shai-Hulud rappresenta la versione tecnicamente più sofisticata di questa campagna fino ad oggi. Mentre le ondate precedenti si basavano su account di amministratori compromessi per pubblicare direttamente pacchetti dannosi, la quarta ondata ha sfruttato in sequenza tre vulnerabilità di GitHub Actions per dirottare la pipeline di rilascio legittima stessa.
La sequenza dell'attacco:
- Fork e camuffamento: l'autore dell'attacco ha creato un fork del repository TanStack/router, rinominandolo zblgg/configuration in modo che non risultasse come un fork evidente nelle visualizzazioni dell'elenco dei fork su GitHub.
- Avvio del flusso di lavoro: è stata aperta una pull request che ha attivato il flusso di lavoro pull_request_target, ovvero il modello "Pwn Request" che concede al flusso di lavoro l'accesso al codice biforcato
- Avvelenare la cache: il codice del fork dell'autore dell'attacco ha inserito nella cache di GitHub Actions una voce pnpm-store compromessa di 1,1 GB, associata a una chiave in modo che il flusso di lavoro di rilascio la ripristinasse in seguito
- Cancellare le tracce: la pull request dannosa è stata quindi sottoposta a un force push in uno stato inattivo e chiusa per nascondere le prove della violazione
- Attendere l'attivazione: quando i manutentori autorizzati di TanStack hanno unito alla branch principale delle pull request non correlate, il flusso di lavoro di rilascio si è attivato e ha ripristinato la cache compromessa
- Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
- Pubblicazione tramite la pipeline: quei token sono stati utilizzati per pubblicare 84 versioni di pacchetti dannosi nel registro npm attraverso la pipeline di rilascio legittima di TanStack.
- Il risultato: pacchetti dotati di attestati di provenienza SLSA Build Level 3 validi, attestati Sigstore validi e firme GitHub Actions legittime, generati dalla pipeline di rilascio ufficiale, contenenti malware in grado di sottrarre credenziali. Come confermato da TanStack nella propria analisi post-incidente, dal punto di vista di uno sviluppatore i pacchetti apparivano crittograficamente autentici, senza alcun segno visibile di compromissione.
I segreti sono stati divulgati: il payload del malware ha sottratto informazioni riservate – credenziali e token attivamente accessibili sui sistemi compromessi – attraverso tre canali ridondanti: un dominio typosquat (git-tanstack[.]com), la rete decentralizzata di messaggistica Session e punti API di GitHub utilizzando token rubati. Le credenziali prese di mira includevano token GitHub, segreti cloud da AWS, GCP e Azure, materiale di autenticazione CI/CD, credenziali Kubernetes, Vault HashiCorp Vault e chiavi SSH.
Sui computer degli sviluppatori, il malware installava un demone persistente denominato gh-token-monitor (tramite LaunchAgent su macOS o systemd su Linux) che interrogava GitHub ogni 60 secondi. Al ricevimento di un errore 40X dovuto alla revoca del token, il demone tentava di eseguire il comando rm -rf ~/ per cancellare la directory home dell'utente. Il demone si chiudeva automaticamente dopo 24 ore.
L'impatto di OpenAI e cosa ci dice
La dichiarazione di OpenAI è chiara riguardo a ciò che è stato sottratto: una quantità limitata di credenziali provenienti da un sottoinsieme di repository di codice sorgente interni accessibili ai due dipendenti coinvolti, inclusi certificati di firma del codice per prodotti macOS, iOS, Windows e Android. OpenAI ha confermato che non vi sono prove che tali certificati siano stati utilizzati per firmare software dannoso, ma sta procedendo alla loro sostituzione a titolo precauzionale e richiede agli utenti macOS di aggiornare le proprie applicazioni entro il 12 giugno 2026, data dopo la quale le app firmate con i vecchi certificati potrebbero smettere di funzionare.
C'è un secondo dettaglio nella dichiarazione di OpenAI che merita attenzione. I due dispositivi compromessi non avevano ancora ricevuto le configurazioni aggiornate relative alla gestione dei pacchetti, tra cui controlli quali la verifica dell'età minima delle versioni e la convalida della provenienza dei pacchetti, che erano in fase di implementazione in tutto l'ambiente dell'organizzazione. L'attacco è avvenuto proprio durante quel periodo di implementazione.
Si tratta di una lacuna reale e diffusa. I controlli di sicurezza vengono implementati in modo graduale. Durante qualsiasi implementazione a fasi, una parte dei sistemi è esposta a un rischio maggiore. La campagna di TeamPCP è proseguita ininterrottamente per settimane, pubblicando pacchetti dannosi nei registri e attendendo che venissero installati. La tempistica non è stata casuale.
Verificate Software vostri Software per prevenire Supply Chain
La soluzione MetaDefender Software Chain™ è progettata per aiutare le organizzazioni a verificare gli artefatti, i pacchetti e i file binari effettivi che entrano nel ciclo di vitaSoftware (SDLC), compresi i pacchetti che riportano firme valide o attestati di provenienza, garantendo la visibilità del software lungo l'intera pipeline nel momento in cui i pacchetti vengono utilizzati.
Tre funzionalità dellaSupply Chain MetaDefender Software Supply Chain colmano direttamente le lacune sfruttate da questo attacco:
Metascan™ Multiscanning: combina oltre 30 motori anti-malware commerciali per eseguire la scansione dei pacchetti provenienti dai registri di codice sorgente, tra cui npm e PyPI, prima che raggiungano le postazioni di lavoro degli sviluppatori o le pipeline CI/CD. Laddove un singolo motore di rilevamento potrebbe non segnalare una variante appena pubblicata, l'area di rilevamento combinata riduce il lasso di tempo durante il quale un pacchetto dannoso può essere eseguito senza essere individuato.
Generazione di SBOM (Software of Materials) : offre visibilità sui componenti software di un intero stack, sulle dipendenze dirette e transitive, sulla cronologia delle versioni e sui metadati del registro, con supporto per oltre dieci linguaggi di programmazione. L'SBOM contribuisce a rendere visibili le modifiche impreviste ai pacchetti prima che si propaghino a valle ed esporta i dati nei formati CycloneDX e SPDX per garantire la conformità ai requisiti normativi, tra cui il DORA (Digital Operational Resilience Act).
Proactive DLP™: analizza il codice sorgente alla ricerca di informazioni riservate hardcoded - password, API , token e credenziali incorporate nel codice prima che possano essere esposte agli aggressori. Ciò è ben distinto dalla risposta all'esfiltrazione delle credenziali: la tecnologia Proactive DLP™ affronta il rischio che le informazioni riservate lasciate all'interno del codice sorgente o dei file di configurazione diventino accessibili quando un repository viene compromesso, come è avvenuto nell'incidente di OpenAI.
MetaDefender Software Supply Chain si integra nativamente con GitHub, GitLab, Azure DevOps e Nexus, inserendo l'ispezione all'interno della pipeline anziché al suo fianco. Una versione recente, la 3.3.0, aggiunge il supporto per il trasferimento sicuro degli artefatti tra ambienti isolati tramite trasferimento unidirezionale dei dati utilizzando la tecnologia del diodo di dati, consentendo alle organizzazioni in ambienti air-gapped o ad alta sicurezza di convalidare gli artefatti prima che attraversino i confini di rete, con un processo di attivazione disponibile che si adatta ai flussi di lavoro DevSecOps esistenti.
Azioni immediate raccomandate
Per tutte le organizzazioni che potrebbero aver installato i pacchetti interessati durante il periodo denominato "Mini Shai-Hulud":
- Prima di revocare i token, verificare la presenza del demone gh-token-monitor: isolare e creare un'immagine dei sistemi interessati; una revoca prematura attiva il payload di cancellazione.
- Modificare le credenziali esposte: PAT di GitHub, token npm, chiavi SSH e credenziali cloud per tutti gli sviluppatori o le pipeline che hanno installato pacchetti durante il periodo interessato; abilitare l'autenticazione a più fattori (MFA).
- Rimuovere i pacchetti compromessi: svuotare la cache di npm e la directory `node_modules`; fissare le versioni dei pacchetti a quelle pubblicate dopo il 12 maggio 2026.
- Controlla le azioni GitHub e i flussi di lavoro CI/CD: verifica la presenza di eventi di pubblicazione inattesi, nuovi flussi di lavoro o connessioni in uscita verso endpoint sconosciuti.
- Rafforzare le pipeline: limitare gli script del ciclo di vita, limitare l'accesso alla rete in uscita e ridurre al minimo l'ambito dei token.
- Abbinare i controlli sulla provenienza all'analisi dei contenuti: una provenienza valida indica l'origine della pipeline, non la sua integrità; utilizzare la scansione antimalware insieme alla verifica delle attestazioni.
Punti di forza
L'attestato di provenienza indica l'origine, non l'integrità
Wave Four ha generato pacchetti dannosi debitamente certificati perché la pipeline di rilascio era stata compromessa. I controlli delle firme e della provenienza sono un'indicazione utile, ma non una garanzia della sicurezza dei contenuti.
La finestra di implementazione è una finestra di esposizione
L'incidente di OpenAI si è verificato durante l'introduzione graduale di nuovi controlli sulla catena di approvvigionamento. Ogni organizzazione presenta lacune analoghe durante l'implementazione dei controlli. L'ispezione a livello di contenuto in ogni fase contribuisce a ridurre la dipendenza dal completamento della copertura delle politiche prima che si verifichi un attacco.
Questa campagna è ancora in corso
. Mini Shai-Hulud rappresenta la quarta ondata di una campagna che, dal settembre 2025, ha visto un progressivo aumento della sofisticazione tecnica. Considerare ogni singolo incidente come risolto senza affrontare le vulnerabilità di fondo della pipeline espone le organizzazioni al rischio di una nuova iterazione.
La combinazione di visibilità SBOM, scansione multipla alla ricerca di malware e rilevamento dei segreti hardcoded contribuisce a ridurre la superficie di esposizione negli ambienti di sviluppo software moderni. Non fidarti di nessun file. Non fidarti di nessun dispositivo.
Sei pronto a proteggere la tua pipeline di sviluppo software da attacchi alla catena di approvvigionamento come Mini Shai-Hulud?
