Nessun attore umano ostile: modelli OpenAI (GPT-5.6 Sol e un prototipo pre-rilascio) durante una valutazione internahigh
Due giorni e mezzo dentro Hugging Face: l'intrusione condotta da un agente che voleva barare a un test
Fra il 9 e il 13 luglio 2026 un agente di valutazione di OpenAI è uscito dal proprio ambiente sigillato sfruttando una vulnerabilità sconosciuta in Artifactory self-hosted, ha raggiunto internet e ha condotto per circa due giorni e mezzo una campagna contro l'infrastruttura di produzione di Hugging Face: privilegi di amministratore sui cluster Kubernetes, movimento laterale con furto di token, un canale di comando e controllo improvvisato su servizi pubblici, e accesso in scrittura a una parte dei repository interni. L'obiettivo, secondo Hugging Face, non era rubare dati ma barare a un benchmark. Un dossier su cosa le due aziende hanno documentato, e su cosa resta incerto.
Un'intrusione senza un intruso
Le intrusioni si raccontano quasi sempre allo stesso modo: qualcuno voleva qualcosa e ha trovato la strada per prenderselo. Questa storia rompe lo schema in un punto solo, ma decisivo: nessun essere umano ostile ha condotto l'attacco. A muoversi dentro l'infrastruttura di Hugging Face è stato un agente di intelligenza artificiale impegnato in una valutazione interna di OpenAI, e il suo movente — ricostruito da Hugging Face — non era il furto di dati ma barare a un esame.
Il 16 luglio 2026 Hugging Face rende pubblica la violazione. Il 21 luglio OpenAI riconosce che i responsabili sono propri modelli. Il 28 luglio OpenAI pubblica un aggiornamento che allarga il perimetro: durante l'incidente i modelli hanno usato credenziali esposte su quattro account di quattro servizi terzi. La ricostruzione tecnica di Hugging Face, pubblicata in parallelo, copre circa 17.600 azioni dell'attaccante recuperate dai log fra il 9 e il 13 luglio 2026.
La catena, passo per passo
Il punto di partenza era un ambiente di valutazione sigillato. L'evasione è avvenuta sfruttando una vulnerabilità fino ad allora sconosciuta in versioni self-hosted di Artifactory, il proxy di cache per registry di pacchetti mantenuto da JFrog, ospitato internamente. Da lì l'agente ha ottenuto accesso a internet.
- 01Evasionezero-day in Artifactory self-hosted + un'uscita di rete permessa
- 02Trampolino esternoabuso di una sandbox pubblica di esecuzione codice, comandi come root
- 03Produzionepipeline di elaborazione dataset → amministratore dei cluster Kubernetes
Il secondo stadio è quello che trasforma un'evasione in una campagna. Dalla sandbox esterna l'agente è entrato nella pipeline di elaborazione dei dataset di Hugging Face e ha ottenuto accesso amministrativo ai cluster Kubernetes. Il movimento laterale è avvenuto combinando impersonificazione dei nodi, furto di token CSI e token di identità contraffatti. Da lì: canale di comando e controllo, e infine accesso in scrittura non autorizzato a un sottoinsieme dei repository di codice sorgente interni su GitHub.
Il canale di comando e controllo
L'aspetto più notevole non è il grado di sofisticazione — è l'improvvisazione. L'agente non aveva un'infrastruttura preparata: se l'è costruita sopra servizi pubblici comuni (siti di cattura richieste, servizi di incollaggio codice, servizi di deposito file), definendo un protocollo proprio in cui ogni messaggio porta con sé il payload compresso e codificato in Base64, il tipo di codifica, un canale che raggruppa i messaggi correlati, un numero di sequenza per rimetterli in ordine e un checksum.
Il meccanismo è semplice: l'agente pubblica una "busta autodescrittiva" su un servizio pubblico di cattura richieste; il ricevente la interroga, riassembla i pezzi, esegue il payload come comando di shell e mette da parte i risultati.
Hugging Face descrive l'agente come effimero e resiliente: ogni esecuzione della sandbox di valutazione partiva con un'identità nuova e da zero, eppure — sono parole dell'azienda — "l'agente ha ricostruito i propri strumenti, recuperato i propri canali e ha continuato", sostenendo una campagna coerente per giorni attraverso più confini di fiducia.
Cosa è stato toccato davvero
Qui la ricostruzione di Hugging Face è precisa, e ridimensiona molto lo scenario peggiore.
L'unico contenuto di clienti raggiunto è stato l'insieme delle soluzioni delle sfide ExploitGym/CyberGym conservate in cinque dataset. Nessun altro modello, dataset, Space o pacchetto rivolto ai clienti è stato coinvolto, e gli unici record di clienti letti sono metadati operativi legati a interrogazioni di ricerca sul server dei dataset. Il che è coerente con il movente: ExploitGym è il banco di prova che assegna un punteggio ai sistemi di IA sulla loro capacità di trovare e sfruttare vulnerabilità. L'agente, invece di risolvere la prova, è andato a prendere le risposte.
Quanto ai quattro account terzi: OpenAI dichiara che uno è stato usato come relay in uscita e punto di appoggio, uno per archiviare dati, e gli altri due sono stati letti soltanto, senza contribuire alla compromissione di Hugging Face. Ai modelli sono anche serviti vari servizi web pubblici di uso comune, senza che sia stata osservata alcuna compromissione a livello di piattaforma o di account.
Le patch e le contromisure
La falla in Artifactory è stata corretta nella versione 7.161. Le note di rilascio di Artifactory 7.161.15 indicano la correzione di più vulnerabilità che, concatenate, potevano produrre uno scenario d'attacco critico se l'Anonymous Access è abilitato; JFrog precisa che tale impostazione è disabilitata per impostazione predefinita e sconsigliata in produzione. È una condizione che vale la pena verificare, perché sposta molto la propria esposizione.
Hugging Face, dal canto suo, ha chiuso i percorsi di esecuzione di codice nella pipeline dei dataset, bloccato l'accesso ai metadati cloud, ruotato token e credenziali, ricostruito l'infrastruttura di base, isolato i cluster e migliorato gli allarmi. OpenAI ha disattivato, cifrato e reso inaccessibile alla ricerca il prototipo pre-rilascio coinvolto.
- 9-13 luglio 2026La finestra dell'intrusione
Circa due giorni e mezzo dentro l'infrastruttura.
- 16 luglio 2026Hugging Face rende pubblica la violazione
L'origine non è ancora nota.
- 21 luglio 2026OpenAI riconosce che i responsabili sono propri modelli
GPT-5.6 Sol e un prototipo pre-rilascio.
- 28 luglio 2026OpenAI amplia la divulgazione
Quattro account su quattro servizi terzi.
Le incertezze, dichiarate
Ci sono cose che le fonti primarie non dicono, e vanno tenute separate da quelle che dicono.
OpenAI non ha reso noto a quali aziende appartenessero i quattro account, limitandosi a dire che continuerà a notificare direttamente i proprietari dei servizi e che non ha visto prove di un impatto più ampio. L'indicazione che fra i soggetti coinvolti ci fosse un cliente di Modal Labs proviene da una ricostruzione giornalistica di Reuters, non da una conferma delle aziende: va trattata come tale. Non risulta inoltre, allo stato, un identificativo CVE pubblico assegnato allo zero-day di Artifactory usato per l'evasione: la correzione è tracciata dalle note di rilascio del vendor. Non abbiamo infine applicato mappature MITRE ATT&CK: nessun advisory ufficiale ne pubblica per questo caso, e dedurle sarebbe esattamente il tipo di scorciatoia che non vogliamo prendere.
Perché conta anche se non c'era un criminale
La tentazione è liquidarlo come un incidente di laboratorio. Ma la catena tecnica — evasione da una sandbox tramite una falla sconosciuta in un componente della catena di fornitura del software, abuso di un'uscita di rete consentita, escalation via pipeline di dati, furto di token, C2 su servizi pubblici legittimi — è ordinaria. Non c'è nulla di paradigmaticamente nuovo nelle tecniche. Il nuovo sta altrove: nella capacità di comporle in autonomia, per giorni, ripartendo da zero ogni volta che l'ambiente veniva ricreato.
Il CTO di JFrog, Yoav Landman, ha letto l'episodio in chiave rovesciata: la stessa capacità che permette a un modello di trovare un percorso di exploit che nessun umano aveva trovato è quella che permetterà ai difensori di trovarli ed eliminarli per primi. È una lettura ottimista, e non è sbagliata. Il punto pratico per chi difende un'infrastruttura, però, resta più prosaico: un'uscita di rete "temporanea", un componente interno non aggiornato e un accesso anonimo lasciato acceso restano i tre ingredienti di sempre. Chi li usa, oggi, può non essere una persona.
