Mistral AI, attacco supply chain: 450 repo in vendita

Mistral AI, attacco supply chain: 450 repo in vendita

Il gruppo TeamPCP ha messo in vendita circa 450 repository interni di Mistral AI al prezzo di 25.000 dollari, minacciando di diffonderli gratuitamente entro una settimana. L’azienda francese ha confermato il 14 maggio 2026 che il 12 maggio un attacco supply chain ha compromesso temporaneamente un sistema di gestione codebase e contaminato alcuni pacchetti SDK, escludendo però che siano stati violati dati utente, servizi ospitati o ambienti di ricerca. L’episodio solleva un problema tecnico profondo: i pacchetti malevoli erano firmati con provenance SLSA valida, rendendo invisibile il compromesso agli strumenti di verifica automatica.

Quando la firma SLSA diventa un blind spot

La campagna Mini Shai-Hulud ha compromesso pacchetti su npm e PyPI, tra cui i SDK di Mistral AI. Secondo l’analisi tecnica di vendor come Wiz, Snyk, Socket e StepSecurity, il gruppo ha abusato di una combinazione di tre classi di vulnerabilità note. "The attacker chained three known vulnerability classes — a pull_request_target 'Pwn Request' misconfiguration, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of the OIDC token from the Actions runner process", ha riferito TanStack security advisory via SecurityWeek.

Per Mistral AI, la compromissione ha riguardato il core SDK, l’integrazione Azure e l’integrazione GCP, con tre versioni maliziose pubblicate per ciascuno. Gli artefatti malevoli non superavano i controlli di provenance perché li avevano prodotti dirottando la pipeline legittima: con il token OIDC rubato hanno ottenuto un certificato Sigstore valido.

"SLSA provenance is a cryptographic certificate, generated by Sigstore, that is meant to verify a package was built from a trusted source. The worm was able to produce these certificates because it hijacked the legitimate build pipeline itself" — Snyk via SecurityWeek

La provenance SLSA è diventata uno standard per attestare che un pacchetto provenga da una pipeline affidabile. Gli sviluppatori e le piattaforme la utilizzano per bloccare automaticamente artefatti sospetti. Quando però l’attaccante controlla la pipeline stessa, il certificato diventa un attestato tecnicamente corretto di un processo tecnicamente compromesso, bypassando i gate automatici senza allarmi.

Il risultato è che un package manager o una policy di sicurezza che si fidasse esclusivamente della firma SLSA avrebbe considerato le versioni maliziose di Mistral AI perfettamente legittime. Questo sposta il problema dalla verifica crittografica alla verifica comportamentale del runner, un livello di controllo che molte organizzazioni non hanno ancora implementato.

Il malware ha poi esfiltrato i dati attraverso canali multipli, tra cui un dominio custom, repository GitHub tematici e la rete Session. "The Session network channel is new. Decentralized and takedown-resistant, it is significantly harder to disrupt than dedicated domains or GitHub-based exfiltration", ha osservato Wiz via SecurityWeek. Socket e StepSecurity hanno sottolineato che la velocità della campagna ha aggravato l’impatto: la propagazione worm-like ha sfruttato la fiducia reciproca tra repository per scalare rapidamente, rendendo difficile l’intervento manuale da parte dei maintainer.

Il mercato nero dei 450 repository: tra claim e verifiche mancanti

Sul forum, TeamPCP ha offerto circa 450 repository interni e una dimensione stimata in circa 5 GB di dati esfiltrati, fissando il prezzo a 25.000 dollari per l’acquisto esclusivo. Il gruppo ha minacciato di renderli pubblici gratuitamente se non dovesse trovare un acquirente entro una settimana. Al momento, però, non esistono prove indipendenti che confermino l’autenticità di questo archivio.

Non è nemmeno chiaro se i repository contengano codice sorgente sensibile, nomi di progetti interni o altro materiale non core. Mistral AI ha esplicitamente escluso che i repository compromessi facessero parte del codice principale, ma non ha verificato il numero esatto di asset esfiltrati né se il furto sia avvenuto tutto il 12 maggio o in un secondo momento. Non è inoltre confermato che le credenziali rubate siano state riutilizzate per accessi oltre ai pacchetti SDK compromessi.

La messa in vendita di codice sorgente interno, anche se non core, rappresenta un rischio reputazionale significativo per un vendor di AI sovrana che compete su modelli proprietari e partnership enterprise. La sola esposizione dei nomi dei progetti interni, delle dipendenze o dei commenti nel codice può offrire a competitor e attacker una mappa dell’architettura tecnica, oltre a fornire punti di ingresso per future campagne di spear-phishing contro i dipendenti.

I confini del danno: cosa conferma e cosa nega Mistral AI

In una dichiarazione diretta a BleepingComputer, Mistral AI ha precisato che gli attacker hanno compromesso il sistema di gestione codebase e che "They [the hackers] contaminated some of our SDK packages for a brief period". I repository toccati non erano parte del core code, secondo la ricostruzione aziendale.

L’azienda ha inoltre escluso che l’incidente abbia toccato l’infrastruttura sensibile. "Neither our hosted services, managed user data, nor any of our research and testing environments were compromised", ha dichiarato un portavoce a BleepingComputer. La linea tracciata da Mistral AI separa nettamente la compromissione del sistema di gestione codebase da quella dei servizi ospitati, anche se al momento non ci sono evidence tecniche pubbliche indipendenti che corroborino integralmente questa ricostruzione.

La distinzione tra repository core e non-core è tecnicamente rilevante, ma non risolve il problema della persistenza. Se l’accesso al sistema di gestione codebase è stato ottenuto tramite token OIDC o credenziali dirottate, non è confermato che le chiavi siano state rotte completamente o che non esistano backdoor nei sistemi di build. La dichiarazione di Mistral AI, sebbene precisa, lascia aperti i punti interrogativi sulla completezza della remediation.

Cosa fare adesso

Le contromisure devono intervenire su più livelli della pipeline, perché nessun singolo controllo avrebbe bloccato questa campagna multi-stadio.

• Auditare pull_request_target: verificare che i workflow GitHub Actions non eseguano codice da fork esterni con privilegi di scrittura sul repository base, disabilitando la misconfiguration nota come "Pwn Request".
• Isolare i runner e ruotare i token OIDC: limitare l’accesso alla memoria dei runner CI/CD, implementare sandboxing e revocare immediatamente i token usati per il signing dei pacchetti, sostituendoli con credenziali fresh.
• Invalidare la cache sospetta: controllare le policy di cache GitHub Actions per impedire il poisoning cross-boundary tra fork e repository base, eliminando artefatti generati da pull request non verificate.
• Rivalutare la catena di fiducia SLSA: la presenza di un certificato Sigstore valido non sostituisce l’analisi del comportamento runtime del pacchetto; integrare scanning comportamentale prima dell’installazione in produzione.

Domande e risposte

Come è possibile che un pacchetto malevolo abbia una firma SLSA valida?
Perché l’attaccante ha dirottato la pipeline CI/CD legittima: con il token OIDC rubato ha ottenuto il certificato Sigstore esattamente come farebbe un build autentico. La firma garantisce solo l’origine della pipeline, non la pulizia del codice sorgente iniettato. Il certificato non analizza il codice, ma solo l’identità del builder.

I repository messi in vendita da TeamPCP sono autentici?
Al momento non esistono prove pubbliche indipendenti che confermino l’autenticità dei circa 450 repository né il loro contenuto. Mistral AI ha confermato un compromesso di sistema ma non ha verificato il volume o la natura esatta dei dati esfiltrati. La mancanza di un hash o di un campione pubblico rende impossibile per terzi validare la merce.

Qual è il rischio per chi ha installato i pacchetti SDK compromessi di Mistral AI?
Le versioni malevole sono state pubblicate per un breve periodo e includevano il core SDK, l’integrazione Azure e quella GCP. Chi le ha installate durante la finestra di esposizione potrebbe aver introdotto nel proprio ambiente codice capace di esfiltrare dati verso Session network. È necessario un audit immediato delle dipendenze e dei log di installazione relativi al 12 maggio 2026.

L’incidente dimostra che la supply chain open-source non è vulnerabile solo per la mancanza di controlli, ma per un eccesso di fiducia nei meccanismi automatizzati di firma. Quando il certificato di provenance diventa la perfetta copertura per un payload malevolo, la verifica deve spostarsi upstream: monitorare il runner, isolare la memoria, invalidare la cache sospetta. Per Mistral AI, la prova del fuoco sarà convincere clienti e sviluppatori che il perimetro esposto è davvero chiuso, mentre il settore attende ancora conferme sui 450 repository messi all’asta.

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

Fonti

• https://www.bleepingcomputer.com/news/security/teampcp-hackers-advertise-mistral-ai-code-repos-for-sale/
• https://hackread.com/teampcp-mistral-ai-repositories-mini-shai-hulud-attack/
• https://cybernews.com/ai-news/mistral-ai-breach-450-repositories-tanstack-teampcp/
• https://x.com/DarkWebInformer/status/2054584505172668754
• https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/