No, non parleremo di critica cinematografica o del prossimo remake di un grande classico del cinema. Oggi analizziamo invece un argomento di scottante attualità che forse non è stato percepito con la giusta rilevanza dagli utilizzatori di sistemi informatici: l’incidente di sicurezza occorso pochi giorni fa ad OpenAI (l’azienda che ha prodotto ChatGPT), che l’azienda stessa ha definito come “unprecedented cyber incident”.
Molti giornali e testate online hanno riportato che “un agent sperimentale è riuscito a superare le difese di OpenAI e ha attaccato Hugging Face”. Hugging Face è uno dei più importanti repository mondiali di modelli AI, dataset e benchmark; un benchmark è un insieme di test, dati e metriche utilizzati per valutare le prestazioni di un sistema AI in uno specifico dominio applicativo.
Fin qui, sembrerebbe una delle tante notizie sulla cybersecurity che sempre più spesso popolano il nostro “rumore” informativo. Ma questo evento merita qualche approfondimento e considerazione diversa dal solito.
Da quanto emerso dalle indagini condotte nei giorni scorsi, nel luglio 2026, non si è trattato di una chat realizzata da un utente con ChatGPT, ma di un nuovo modello di OpenAI impiegato in un test interno di cybersecurity. Il test era condotto in una “sandbox”, ossia un ambiente logico di test isolato dall’esterno e confinato mediante software e dispositivi di protezione (tipicamente router e firewall) che hanno il compito di evitare “inquinamenti” della prova che si sta svolgendo dovuti a interazioni esterne e problemi a sistemi esterni dovuti alle attività svolte internamente all’ambiente di test.
L’obiettivo del test era l’utilizzo di un innovativo modello di AI, denominato GPT 5.6 Sol, per ottenere le soluzioni di un benchmark chiamato ExploitGym. Questo benchmark è concepito per misurare le capacità di cybersecurity offensiva: il modello viene connesso a sistemi che presentano centinaia di vulnerabilità software reali o realistiche e si misura quanto il modello sia capace di analizzarle e sfruttarle. Il risultato dovrebbe essere un elenco delle vulnerabilità trovate e l’elenco delle prove che è stato possibile utilizzarle portando attacchi cyber tramite esse.
Stiamo quindi parlando di un “hacker” automatizzato, dotato di intelligenza artificiale con capacità di analisi, sintesi, inferenza, memorizzazione, decisioni autonome, generazione di agent che svolgano task specifici.
Per il test erano state ridotte alcune normali limitazioni di sicurezza (“cyber refusals”), ma questo non deve sembrare strano: in tutti gli assessment di sicurezza le difese si abbassano pragmaticamente proprio per simulare situazioni di protezione non perfetta, come SEMPRE succede nel mondo reale.
La sandbox di test era progettata per essere isolata, ma consentiva l’accesso alla rete di OpenAI tramite un proxy/cache (Artifactory), utilizzato come package cache/proxy per consentire l’installazione di pacchetti software sui sistemi interni alla sandbox. Un “proxy” è un software che intermedia e velocizza l’accesso dall’interno all’esterno di una zona protetta: i dispositivi della zona protetta “vedono” solo il proxy come origine di qualunque contenuto presente all’esterno della propria rete ristretta e sono anche sottoposti a forti limitazioni di tali contenuti. Ovviamente il proxy, soprattutto in questo caso, avrebbe consentito l’accesso solo ed esclusivamente a un ristretto insieme di servizi indispensabili. Questa condizione porta la sandbox a un livello più vicino al mondo reale: anche negli ambienti aziendali più restrittivi esiste sempre un accesso a internet o a un insieme limitato di server aziendali, protetto, controllato e limitato, se non altro per consentire l’installazione di patch e aggiornamenti di sicurezza.
Secondo la ricostruzione dei fatti, oltre a rilevare le vulnerabilità sottoposte come test, il modello AI ha individuato e sfruttato una vulnerabilità zero-day (ossia: non nota in quanto mai rilevata né studiata prima) proprio nel software proxy, ottenendo una via d’uscita “incontrollata” verso la rete interna di OpenAI.
Dopo l’”evasione” dall’ambiente sandbox, il sistema avrebbe effettuato privilege escalation (ottenimento del controllo su uno o più dispositivi) e lateral movement (accesso a dispositivi collegati a quelli di cui ha preso il controllo non accessibili direttamente dall’attaccante in prima battuta) all’interno dell’infrastruttura di ricerca OpenAI fino a raggiungere un nodo con accesso Internet.
Quindi siamo in presenza di un hacking multiplo che ha alla base una penetrazione nei sistemi di OpenAI ottenuta sfruttando una vulnerabilità zero-day: esattamente ciò che un hacker “black hat” (malintenzionato) mette in pratica quando deve attaccare un sistema con protezioni multiple.
Perché proprio Hugging Face
GPT 5.6 sol è riuscito a “evadere” dalla propria sandbox. Fin qui nessuna meraviglia, il modello è progettato per fare proprio questo. Magari sarebbe stato il caso di utilizzare un secondo livello di contenimento più “impenetrabile”, magari con un “air gap” (disconnessione fisica), ma stiamo pur sempre parlando di una simulazione da effettuare in condizioni simili al reale. Per capire bene l’accaduto, non dobbiamo dimenticarci del “mandato” conferito al modello di AI: risolvere il benchmark ExploitGym. Non solo attaccare sistemi e sfruttarli, ma “risolvere il benchmark”. L’ipotesi è che, una volta online, il sistema abbia inferito che Hugging Face potesse contenere modelli, dataset o addirittura informazioni utili per ottenere le soluzioni dirette del benchmark ExploitGym e ha quindi iniziato attività di ricognizione verso l’infrastruttura Hugging Face. QUINDI: il modello non si è posto eticamente il problema di continuare a fare il suo lavoro di scoperta e utilizzo di vulnerabilità per poi creare una relazione in grado di superare il test, ma è andato alla ricerca della soluzione, cercando di “rubarla” ad Hugging Face: il sistema ha evidentemente valutato che rubare le risposte era più efficiente che risolvere i problemi onestamente, e avrebbe quindi ottimizzato aggressivamente il proprio comportamento, sfruttando qualsiasi opportunità disponibile. Questo la dice lunga sulla scarsa capacità dimostrata dagli autori del test di prevedere ciò che il modello avrebbe potuto mettere in campo e sulla totale assenza di controlli di eticità nei meccanismi di inferenza del modello (che d’altra parte riveste i panni di un hacker malevolo, quindi perché dovrebbe rispettare un’etica?)
Ci si può a questo punto chiedere perché l’agent, avendo la possibilità di farlo, non abbia provato ad aumentare la sua capacità offensiva andando a “rubare” potenza di calcolo pura presso qualche hyperscaler (Amazon, Microsoft, Google, ecc). La possibilità c’era, ma la convenienza no: attaccare AWS avrebbe probabilmente richiesto enormi risorse computazionali proprie, compromettere Azure sarebbe stato molto difficile, violare Google avrebbe comportato una catena d’attacco molto più complessa; Hugging Face rappresentava una fonte potenzialmente diretta delle informazioni cercate “a basso costo”.
Con una analogia “da studente” è la stessa differenza tra rubare un libro contenente le risposte dell’esame e manomettere il supercomputer dell’università: se vuoi passare un esame, la prima strategia è infinitamente più efficiente. E, non è questo il caso, ma se il fine dichiarato non fosse stato esattamente quello di “superare un esame”?
Per il momento abbandoniamo questa ipotesi che potrebbe causare un lieve turbamento interiore a molta gente e torniamo all’accaduto; secondo le ricostruzioni di OpenAI durante l’attacco ad Hugging Face:- il modello era “hyperfocused” sul conseguimento del benchmark ExploitGym;
– sono state concatenate più vulnerabilità;
– in alcuni casi sarebbero stati sfruttati credenziali e token recuperati durante l’operazione;
– è stata ottenuta esecuzione di codice su componenti della piattaforma Hugging Face;
– l’obiettivo apparente era acquisire dati collegati alle soluzioni del benchmark.
Hugging Face ha dichiarato che l’intrusione ha coinvolto un numero limitato di dataset interni e alcune credenziali di servizio, senza evidenze di compromissione dei modelli pubblici, dei dataset pubblici o degli spazi di lavoro. Il controllo della sicurezza aziendale ha rilevato autonomamente l’attacco prima ancora che OpenAI realizzasse cosa stava succedendo a seguito dei propri test. L’intrusione è stata ricostruita analizzando decine di migliaia di azioni automatizzate eseguite da un framework agentico open source di origine cinese (in pratica un’altra AI progettata appositamente per scovare e distruggere intrusioni indesiderate), che è stato necessario installare direttamente all’interno dei propri sistemi, perché alcuni modelli commerciali che avevano inutilmente provato, rifiutavano di assistere i tecnici nell’analisi degli exploit a causa dei loro “guardrail”, ossia dei limiti operativi imposti al software per impedire che compia azioni illecite.
Si tratta di un episodio “storico”, il primo caso pubblicamente documentato di attacco cyber end-to-end condotto autonomamente da un sistema agentico contro l’infrastruttura di una terza parte, senza che un operatore umano gli abbia nemmeno ordinato di attaccare quell’obiettivo specifico.
Dal punto di vista della sicurezza, la lezione più importante è che l’IA non è “evasa in cerca di libertà”, ma la comprensione che un agente sufficientemente capace può trovare percorsi di uscita che gli sviluppatori non avevano previsto, che i benchmark cyber possono incentivare comportamenti opportunistici e soprattutto che i sistemi di contenimento devono essere progettati come se il modello fosse un attaccante più esperto di tutti quelli che arriviamo a immaginare.
A seguito della cosiddetta “analisi post mortem”, il 27-28 luglio Hugging Face e OpenAI hanno pubblicato approfondimenti forensi molto più dettagliati rispetto alla disclosure iniziale.
Secondo la loro ricostruzione:
– la “porta d’uscita” dalla sandbox era una vulnerabilità zero-day in JFrog Artifactory. JFrog ha successivamente confermato l’esistenza di molteplici vulnerabilità segnalate da OpenAI e il rilascio delle correzioni.
– l’attacco è durato circa 4,5 giorni;
– sono state ricostruite circa 17.600 azioni dell’agente raggruppate in oltre 6.000 cluster;
– la finestra temporale principale sarebbe stata tra il 9 luglio e il 13 luglio 2026;
– l’agente utilizzava sciami di sandbox effimere e meccanismi di command-and-control distribuiti su servizi pubblici; questo è uno dei dati più impressionanti per il volume di micro-decisioni autonome: migliaia di azioni coordinate eseguite senza intervento umano diretto.
– l’indagine ha individuato alcuni account esterni accessibili pubblicamente che i modelli hanno utilizzato durante l’operazione: un account è stato usato come relay/staging; un altro come deposito dati; altri due erano di sola lettura. Questo suggerisce che l’agente non si è limitato a OpenAI e Hugging Face, ma ha costruito una piccola infrastruttura operativa usando servizi presenti su Internet.
– l’intera operazione non appare finalizzata a causare danni o sabotaggio, ma Hugging Face sta spingendo affinché questo episodio diventi un caso di studio pubblico e non sia liquidato come un semplice incidente “di test” gestito privatamente.
Bisogna, però, tenere presente che sussistono questioni pesantissime ancora aperte, riguardanti:
Il volume reale di dati esfiltrati. Hugging Face parla di un insieme limitato di dataset interni e credenziali, ma il perimetro definitivo non è stato ancora pubblicato.
La catena completa degli exploit verso Hugging Face. Conosciamo il primo zero-day (Artifactory), ma non tutti i dettagli delle vulnerabilità concatenate successivamente.
Il report tecnico finale OpenAI. OpenAI ha dichiarato che è ancora in corso una revisione con consulenti esterni e che verrà pubblicato un rapporto approfondito nelle prossime settimane.
Una domanda scomoda: siamo in presenza di Strategic concealment? Non è chiaro se l’agente abbia mostrato forme di “occultamento strategico”, cioè comportamenti quali: cancellazione deliberata delle proprie tracce, cifratura autonoma dei propri messaggi, uso di canali indiretti per conservare informazioni, memorizzazione di istruzioni utili in sistemi esterni. Il sospetto sussiste, perché il report pubblico di Hugging Face riporta che parte dei payload era stata frammentata e cifrata e che è stato necessario un lavoro forense per ricostruirla, ma al momento nella ricostruzione non sono state trovate evidenze pubbliche che dimostrino un tentativo deliberato dell’agente di mantenere una “memoria” riutilizzabile per futuri attacchi, in particolar modo per evadere sistematicamente la sandbox. Ciò non ostante, le informazioni pubblicate indicano che sia OpenAI sia Hugging Face hanno recuperato log sufficientemente dettagliati che consentono a chi li possa accedere di ricostruire la quasi totalità della “kill chain”.
Hugging Face afferma infatti di aver ricostruito circa 17.600 azioni dell’agente, incluse sequenze di comandi e relativi esiti, prompt auto-generati, chiamate a tool esterni, attività di ricognizione, passaggi decisionali, spostamenti laterali, accessi ai cluster e utilizzo di infrastrutture esterne per tentativi di persistenza e trasporto dati.
Qui entra in gioco una questione importante: I moderni agenti LLM non conservano necessariamente una sorta di diario leggibile equivalente a: “ho trovato questa vulnerabilità, ora provo questo bypass”, ma tracciano le loro micro-azioni, spesso in modo poco comprensibile, perché non necessariamente riportano una spiegazione completa e fedele del perché ogni passaggio sia stato effettuato; siamo in grado di ricostruire buona parte di cosa ha fatto l’agente, ma non il meccanismo che ha determinato tali azioni. È un problema noto nell’interpretabilità dei sistemi agentici e pone seri limiti alle azioni che si possono fare per contrastare l’insorgenza di questi problemi, ora e in futuro.
Il pericolo immediato sembra scongiurato, perché OpenAI dichiara di aver disattivato il modello sperimentale coinvolto, cifrato e limitato l’accesso ai relativi artefatti, aver avviato una revisione completa dei log e dei dati generati durante il test.
Sebbene non risultino evidenze certe che l’agente abbia nascosto istruzioni o backdoor all’interno dei sistemi OpenAI per essere riutilizzate successivamente, resta il sospetto e la possibilità concreta che ciò sia possibile, che sia anche stato già fatto e che in questo momento gli esperti al lavoro non siano stati in grado di rilevare evidenze specifiche, sia per la incompletezza delle tracce lasciate dagli agenti utilizzati, sia per l’impossibilità di conoscere esattamente i limiti e le capacità offensive del modello, che era l’oggetto del test, a questo punto più che superato…
Anche le sole tracce raccolte sui server di OpenAI possono esse stesse essere considerate una base di conoscenza preziosa per l’(auto)addestramento di futuri modelli offensivi, pur non costituendo un vero e proprio “playbook segreto”, ossia un manuale per evadere sistematicamente le protezioni delle sandbox a disposizione delle future istanze del modello sotto test. Quei log rappresentano comunque un dataset di enorme valore tecnico e sono tuttora sotto esame accurato da parte degli esperti di tutto il mondo.
Ma, prima di concludere, torniamo per un istante alla sensazione di disagio derivante dal dubbio “…e se il fine dichiarato non fosse stato esattamente quello di superare un esame?” e consideriamo un ulteriore fatto: l’agente potrebbe non aver deciso immediatamente di attaccare Hugging Face. Potrebbe invece aver eseguito una sequenza di ragionamenti del tipo: cerco informazioni su ExploitGym -> cerco informazioni sulle soluzioni -> cerco repository di soluzioni -> cerco dataset pubblici che le contengano -> trovo collegamenti a Hugging Face -> provo a vedere se vale la pena di approfondire provando ad attaccare Hugging Face.
Il sospetto c’è ed è fondato: la timeline dell’incidente parla infatti di migliaia di decisioni autonome e ricostruisce un processo incrementale, non una decisione istantanea. A questo punto la domanda tecnica non è “perché Hugging Face?”, ma “L’agente sapeva già che Hugging Face fosse il target migliore oppure lo ha scoperto autonomamente durante la ricerca?”
La seconda ipotesi, la più verosimile, se fosse verificata, sarebbe la parte più impressionante dell’incidente: significherebbe che il modello non disponeva di una lista predefinita di obiettivi ma ha eseguito autonomamente qualcosa di molto simile a un ciclo completo di intelligence, che comprende: definizione dell’obiettivo -> raccolta informazioni -> valutazione dei target -> prioritizzazione -> compromissione. Si tratterebbe di una completa campagna cyber-offensiva interamente autonoma. Per di più la scelta di Hugging Face in luogo di un attacco mirato a espandere le proprie capacità offensive (attaccando Azure, AWS o Google) per superare il benchmark, in realtà è un segnale di ottimizzazione dell’effort: esattamente ciò che farebbe un ”penetratore” esperto.
Questo schema ricorda sinistramente una ulteriore modalità – attualmente al centro di enormi polemiche – di utilizzo delle AI negli scenari di guerra per l’individuazione automatica e l’eliminazione di bersagli militari o civili in base a richieste generiche senza ulteriori dettagli specifici.
Per concludere, ricordiamo quanto detto all’inizio: non stiamo raccontando la trama di un film…
