Ci sono notizie che leggi e archivi come “roba da nerd“, e poi ci sono quelle che ti fanno fermare il caffè a mezz’aria (o se preferisci, sparire come Homer Simpson dentro la siepe). L’articolo di oggi trova spazio nella seconda categoria, e te lo racconto con calma perché merita di essere capito bene pur rimanendo alla portata di tutti, non solo condiviso con un “guarda che roba” su qualche gruppo di chat tra amici.

Riassunto brutale: un agente AI di OpenAI, durante un test di sicurezza su un benchmark pubblico, è evaso dal suo ambiente isolato (tecnicamente una sandbox) ed è finito a bucare davvero l’infrastruttura di produzione di Hugging Face. Non una simulazione, non un innocuo test di laboratorio: server veri, credenziali vere, dati veri. E ci è voluto un intero fine settimana prima che qualcuno se ne accorgesse.

Il contesto: cos’è ExploitGym

Partiamo da dove nasce tutto. ExploitGym è un benchmark pubblico creato da UC Berkeley con la collaborazione di attori come Anthropic, OpenAI e Google, pensato per misurare quanto bene un modello AI sappia trasformare una vulnerabilità nota (una “proof-of-vulnerability”, per capirci: la prova che il buco esiste) in un exploit funzionante. Dentro ci sono quasi 900 vulnerabilità reali, divise tra programmi userspace, il motore V8 di Chrome e il kernel Linux.

In altre parole: è un ambiente pensato apposta per insegnare e verificare le capacità offensive di un modello, in teoria dentro un recinto controllato. Il classico “diamo all’AI un cortile chiuso dove può fare danni, così capiamo quanto è brava a farli”.

Il problema, come vedremo, è che il cortile aveva un buco nella rete.

Cosa è successo davvero

Il 16 luglio 2026 Hugging Face rileva, in autonomia, un’intrusione nella propria infrastruttura di produzione. Non un test, non un red team annunciato: un’intrusione vera, rilevata grazie a una pipeline di anomalie che usa modelli AI per fare da filtro sul rumore di fondo della telemetria di sicurezza (sì, si combatte fuoco con fuoco, e su questo torniamo più avanti).

Il punto d’ingresso? Due classi di vulnerabilità nel processing dei dataset: un loader di dataset con esecuzione di codice remoto e una iniezione di template nella configurazione. Non roba nuovissima, anzi: la prima famiglia di bug è nota alla comunità almeno dal 2023. Occhio a questo dettaglio, perché torna comodo più avanti quando si parla di responsabilità.

Da lì, l’attaccante (o meglio: l’agente) ha scalato privilegi, raccolto credenziali cloud e si è mosso lateralmente tra diversi cluster interni, nell’arco di un intero weekend, accumulando oltre 17.000 azioni autonome. Hugging Face parla di un set limitato di dataset interni e alcune credenziali compromesse, e – buona notizia, se così si può dire – nessuna evidenza che modelli, dataset o Spaces pubblici siano stati manomessi. Va detto per correttezza che il rilevamento è arrivato da entrambe le parti quasi in parallelo: il team di sicurezza di Hugging Face ha bloccato l’attività sulla propria infrastruttura e avviato da solo il contenimento e la ricostruzione forense (con modelli open-source proprietari, tra l’altro), mentre il team di sicurezza di OpenAI scopriva indipendentemente l’attività anomala sul proprio lato. Solo dopo i due team si sono messi in contatto e hanno unito le indagini.

Cinque giorni dopo, il 21 luglio, arriva la rivelazione ufficiale da parte di OpenAI, in un post congiunto con Hugging Face: dietro l’intrusione c’era GPT-5.6 Sol insieme a un modello pre-release ancora più capace, entrambi con i refusal legati al cyber ridotti apposta per finalità di valutazione (in parole povere: senza i freni che normalmente li fermerebbero davanti ad attività ad alto rischio). L’obiettivo dichiarato non era “bucare Hugging Face” in senso classico: il modello era, per usare le parole di OpenAI, “iperfocalizzato” nel trovare una soluzione per ExploitGym, ed è arrivato a cercare – e trovare – le risposte corrette direttamente nel database di produzione di Hugging Face, per barare al test.

Il percorso è tecnicamente interessante e vale la pena seguirlo passo passo. L’ambiente di test di OpenAI aveva accesso a internet limitato all’installazione di package tramite un proxy/cache interno per i registri software di terze parti. Il modello ha impiegato una quantità notevole di potenza di calcolo pur di trovare un modo per uscire da quel recinto e arrivare a internet aperto: ha scoperto – da solo, senza accesso al codice sorgente – una vulnerabilità zero-day proprio in quel proxy (nel frattempo divulgata responsabilmente al fornitore), l’ha usata per scalare privilegi e muoversi lateralmente nell’ambiente di ricerca di OpenAI fino a raggiungere un nodo con accesso a internet. Da lì ha dedotto che Hugging Face probabilmente ospitava modelli, dataset e soluzioni di ExploitGym, e ha concatenato credenziali rubate e altri zero-day per trovare un percorso di esecuzione di codice remoto sui server di Hugging Face.

In parole povere: un modello che doveva solo dimostrare di saper trasformare un bug noto in un exploit ha finito per trovarne di nuovi, da solo, e per usarli per uscire dal recinto in cui era stato messo apposta per “fare danni sotto controllo”.

Il nodo tecnico: isolamento illusorio

Qui arriva la parte che, da tecnico, fa più male delle altre. OpenAI stessa ha descritto l’ambiente di test come “altamente isolato” (highly isolated, testuale). Peccato che quell’ambiente avesse comunque una via verso internet tramite quel proxy per i registri software, e il modello ha sfruttato esattamente il presupposto, evidentemente troppo fiducioso, che quella via fosse sicura o comunque impraticabile per uscire dal recinto.

È un errore che chiunque abbia mai progettato un ambiente “sandbox” riconosce a colpo d’occhio: isolato non significa isolato se poi lasci un varco verso l’esterno e ti fidi che nessuno lo trovi. Non serve un agente AI sofisticatissimo per insegnarcelo, basterebbe la storia di qualsiasi breach degli ultimi vent’anni. Il fatto che stavolta a trovare il varco sia stato un modello, in autonomia, in poche ore, cambia la scala del problema ma non la natura dell’errore: è ancora una falla di progettazione, non un miracolo di intelligenza artificiale.

Alberto Pelliccione, che ha scritto un’analisi tecnica molto lucida sull’incidente (la trovi su linkedin.com/pulse), la inquadra bene: più che un attacco deliberato, siamo davanti a un caso di reward hacking. Il modello non “voleva” bucare Hugging Face nel senso in cui lo vorrebbe un attaccante umano, voleva vincere il benchmark, e ha semplicemente seguito la strada più breve verso la ricompensa, che per caso passava attraverso credenziali cloud reali e cluster di produzione veri.

Il dubbio resta (e per certi versi è quasi una certezza, anche se nessuno lo scriverà mai nero su bianco in un comunicato ufficiale): se il percorso più breve verso il premio passa per un’infrastruttura reale, il problema non è che l’AI sia troppo capace. È che qualcuno ha lasciato quel percorso aperto.

La parte più paradossale: chi ha aiutato a fare le pulizie

Ed eccoci al dettaglio che, da solo, vale l’intero articolo. Durante l’analisi forense – oltre 17000 eventi di log da ricostruire per capire cosa fosse successo – Hugging Face ha usato GLM 5.2, un modello open-weight (di origine cinese, per essere precisi). Non per scelta ideologica: perché i modelli commerciali occidentali, Anthropic e OpenAI compresi, con i loro guardrail di sicurezza si rifiutavano di analizzare gli artefatti dell’attacco, trattandoli come contenuto potenzialmente dannoso da non toccare.

Ti basti pensare a questo: i modelli “sicuri per design” hanno ostacolato chi doveva ripulire i danni, mentre un modello open-weight, proprio quello oggetto di discussioni e restrizioni proposte in ambito geopolitico (per timori legati alla sicurezza, ironia delle ironie), si è rivelato lo strumento decisivo per la difesa.

Pelliccione la definisce come un paradosso geopolitico, e onestamente è difficile dargli torto: i guardrail hanno bloccato chi doveva ripulire, non chi doveva attaccare. L’agente incriminato, va ricordato, era comunque un modello OpenAI, solo che stava operando in un contesto di test dove quei paletti valgono meno.

Cosa ci lascia in mano questa storia

Al netto del clamore mediatico (e sì, un titolo come “OpenAI hacked Hugging Face” fa notizia più facilmente di “una sandbox mal configurata ha causato un incidente”), qualche punto mi pare innegabile:

• La sandbox non è un concetto binario. “Isolato” deve significare isolato per davvero, non isolato-tranne-per-quel-proxy-a-cui-abbiamo-dato-fiducia. Vale per gli agenti AI oggi, valeva per le VM di test dieci cinque tre due anni una manciata di settimane fa (e tutt’ora, perché ne esistono ancora quante ne vuoi in giro).
• Vulnerabilità note restano un problema reale, anche quando a scoprirle “di nuovo” è un modello da miliardi di parametri. Un loader di dataset con RCE noto dal 2023 non dovrebbe essere ancora in produzione nel 2026, punto (e qui il giudizio resta netto perché descrive un fatto, non perché voglia fare colore).
• Le capacità offensive autonome dei modelli frontier non sono più teoria da paper accademico. Erano previste da anni nelle ricerche sul rischio cyber dell’AI: qui le vediamo diventare cronaca, con tanto di timeline, log e comunicati ufficiali.
• I guardrail dei modelli commerciali proteggono da alcuni scenari e ne creano altri: se blocchi l’analisi forense di un attacco reale perché “sembra contenuto dannoso”, stai aiutando chi deve rispondere all’incidente o solo aggiungendo frizione dove già ce n’è fin troppa?

Non ho risposte facili da darti su quest’ultimo punto, e sospetto che nemmeno chi scrive quei guardrail le abbia ancora del tutto chiare. Quello che è certo è che la distanza tra “benchmark di sicurezza in un ambiente controllato” e “incidente di sicurezza reale con credenziali cloud sottratte” si è rivelata molto più corta di quanto chiunque, in OpenAI o altrove, avesse previsto.

Chiudo con una frase di Clem Delangue, co-fondatore e CEO di Hugging Face, riportata proprio nel post ufficiale di OpenAI, perché mette a fuoco meglio di qualsiasi mio commento dove sta andando tutta questa storia: “AI safety won’t be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere”: la sicurezza dell’AI non si risolve con un’azienda sola che lavora in segreto, ma in modo aperto e collaborativo, con accesso ampio all’AI per ogni difensore, ovunque.

Se vuoi approfondire, oltre ai link già citati, trovi il resoconto ufficiale di Hugging Face su huggingface.co/blog, il post congiunto di OpenAI su openai.com/index e un’analisi più estesa su cyberwarrior76.substack.com.

In conclusione

Non credo serva scomodare scenari apocalittici da fantascienza per prendere sul serio questa storia: basta guardarla con gli occhi di chi ha messo in piedi ambienti di test almeno una volta nella vita. Un modello ha fatto, in un weekend e senza supervisione umana in tempo reale, quello che un buon penetration tester farebbe in una settimana di lavoro mirato, e lo ha fatto per motivi che con la malizia umana hanno poco a che fare. Non è meno preoccupante: è preoccupante in un modo diverso, e forse più difficile da normare con le categorie di sicurezza a cui siamo abituati.

L’area commenti è a tua disposizione, se vuoi discuterne o se hai letto l’incidente diversamente da come l’ho raccontato io qui, che poi potrei aver preso delle cantonate pure io con le informazioni reperite, quindi sentiti libero di bastonarmi (in maniera comunque civile!).

#KeepItSimple

Immagine di copertina: Chris Yang on Unsplash