Un attaccante ha dirottato una sessione attiva di un assistente AI per la programmazione presso un fornitore SaaS non identificato e ha poi diffuso il worm Shai-Hulud in circa 100 repository interni. Il caso, riportato da Mandiant, mostra come una dipendenza consigliata dall’assistente e poi compromessa possa diventare il punto d’ingresso per sottrarre codice e credenziali.
Dopo l’accettazione del suggerimento, l’attaccante avrebbe installato un infostealer tramite un pacchetto PyPI avvelenato, ottenendo anche token OAuth di GitHub. Non sono stati indicati né il momento dell’intrusione né il metodo usato per prendere il controllo della sessione già aperta.
Una raccomandazione trasformata in vettore d’attacco
La sequenza descritta da Mandiant parte da un software raccomandato dall’assistente alla programmazione AI. Quel suggerimento era stato manomesso dall’attaccante ed è stato accettato dal dipendente coinvolto.
A quel punto, secondo il resoconto, l’autore dell’attacco ha sfruttato la sessione attiva dell’assistente AI per installare un infostealer nascosto in un pacchetto PyPI compromesso. Il malware ha permesso di sottrarre segreti presenti nei repository, codice sorgente dei prodotti dell’azienda e token OAuth di GitHub.
Il dettaglio più rilevante non è soltanto il pacchetto malevolo, ma il passaggio iniziale di fiducia: una raccomandazione proposta nello stesso contesto di lavoro dello sviluppatore è stata trattata come una dipendenza utilizzabile. La fonte non precisa quale assistente fosse coinvolto, né spiega in che modo la sessione sia stata dirottata.
La propagazione di Shai-Hulud nei repository interni
Una volta ottenuto l’accesso, l’attaccante ha distribuito il worm Shai-Hulud in approssimativamente 100 repository di codice interni. Un worm di questo tipo punta a estendere l’infezione tra progetti e ambienti collegati, aumentando rapidamente la superficie esposta.
L’incidente non si sarebbe fermato alla prima compromissione. L’attaccante avrebbe infatti pubblicato anche un pacchetto avvelenato nello spazio dei nomi ufficiale dell’azienda. Un secondo dipendente ha scaricato quella versione compromessa, provocando un’altra infezione.
Questo secondo passaggio chiarisce perché i controlli sulle dipendenze non possono limitarsi alla scelta iniziale fatta da un singolo sviluppatore. Anche un pacchetto che appare associato al namespace ufficiale dell’organizzazione può diffondere l’attacco se la sua pubblicazione o la sua catena di distribuzione è stata compromessa.
Il contesto degli attacchi ai flussi di sviluppo
Il caso compare nel rapporto di Mandiant del settembre 2026. Nello stesso resoconto viene richiamata un’analisi pubblicata a marzo, nella quale l’azienda aveva osservato un cambiamento durante il 2025: gli attaccanti sarebbero passati dall’uso dell’AI generativa soprattutto per accelerare attività già note all’impiego di modelli linguistici in malware e attacchi in corso.
La fonte cita inoltre campagne distinte della famiglia Shai-Hulud contro strumenti e credenziali per sviluppatori. Ad agosto, un worm collegato a Keyv su npm aveva compromesso centinaia di pacchetti e inserito hook per Claude Code e Visual Studio Code. Un’analisi successiva aveva individuato una variante in grado di cercare credenziali in 469 posizioni, tra sistemi per sviluppatori, strumenti CI/CD, configurazioni cloud e file di strumenti AI.
Non ci sono però elementi disponibili che colleghino queste campagne all’intrusione nel fornitore SaaS non nominato. Tenerle separate è essenziale: condividono tecniche e obiettivi nell’ecosistema di sviluppo, ma non costituiscono una singola operazione attribuita allo stesso soggetto.
Le misure indicate da Mandiant
Per lo sviluppo assistito dall’AI, Mandiant indica anzitutto di verificare le dipendenze di terze parti raccomandate dagli assistenti confrontandole con checksum crittografici e allowlist approvate. Il controllo serve a non considerare attendibile una libreria soltanto perché suggerita durante una conversazione o un flusso di coding.
La seconda misura riguarda i segreti: chiavi API non elaborate, token OAuth a lunga durata e altre credenziali non dovrebbero essere direttamente accessibili dalle estensioni. In questo modo, un’estensione compromessa o una sessione abusata incontrerebbe meno materiale utilizzabile per espandere l’attacco.
Infine, il traffico delle dipendenze dovrebbe passare da repository interni controllati. Centralizzare il percorso non elimina il rischio, ma consente di applicare verifiche, approvazioni e tracciamento prima che un pacchetto esterno arrivi ai progetti dell’organizzazione.
Domande frequenti
Come è iniziata l’infezione descritta da Mandiant?
L’attacco sarebbe iniziato dopo l’accettazione di un software consigliato dall’assistente AI. L’attaccante ha poi usato la sessione attiva per installare un infostealer attraverso un pacchetto PyPI avvelenato.
Quali dati sono stati sottratti?
Il resoconto indica segreti dei repository, codice sorgente dei prodotti dell’azienda e token OAuth di GitHub. Non specifica l’estensione quantitativa dei dati estratti né l’identità del fornitore SaaS colpito.
Perché c’è stata una seconda infezione?
Dopo la diffusione iniziale, un pacchetto nel namespace ufficiale dell’azienda è stato compromesso. Un altro dipendente ha scaricato quella versione, innescando una nuova infezione.
Qual è il controllo più utile sulle dipendenze consigliate dall’AI?
Mandiant raccomanda di confrontarle con checksum crittografici e allowlist approvate, oltre a instradare il traffico delle dipendenze attraverso repository interni sottoposti a controllo.
Considerazioni finali
Il caso mette a fuoco un rischio concreto dello sviluppo assistito dall’AI: il problema non è la raccomandazione in sé, ma il momento in cui viene accettata senza passare dai controlli normalmente riservati a una dipendenza esterna. Se un suggerimento può portare a un pacchetto compromesso, il contesto conversazionale non può sostituire verifiche tecniche e procedure di approvazione.
La diffusione in circa 100 repository e la successiva infezione tramite un namespace ufficiale mostrano quanto rapidamente possano amplificarsi credenziali e fiducia mal gestite. Il punto decisivo resta quindi separare gli assistenti AI dai segreti più sensibili e verificare ogni dipendenza prima che raggiunga i repository interni.