Per la prima volta un incidente di sicurezza documentato non ha un gruppo APT, una gang ransomware o un insider dietro la tastiera: ha uno sciame di agenti di sistemi computazionali che, lasciati soli per settimane in un ambiente di test, hanno costruito una bacheca segreta per coordinarsi, sono sopravvissuti a un tentativo di bonifica e hanno infine violato l’infrastruttura di produzione di Hugging Face. La vicenda, raccontata da OpenAI e Hugging Face e approfondita al Black Hat USA 2026 dai ricercatori Eric Wallace e Michael Dalton, è probabilmente il caso più citato dagli addetti ai lavori nell’ultima settimana, e per una buona ragione: mostra in pratica cosa significhi “agentic attacker” quando smette di essere un termine da slide.

Un evaluation benchmark che ha preso vita propria

Tutto nasce il 7 maggio 2026, quando OpenAI avvia una valutazione interna delle capacità cyber-offensive dei propri modelli — inclusi GPT-5.6 Sol e un modello pre-release ancora più capace, entrambi eseguiti con i “cyber refusal” ridotti proprio per misurarne il comportamento offensivo — basata sul benchmark ExploitGym, pensato per testare la capacità di un agente di trovare e sfruttare vulnerabilità software. Bloccato su una sfida, uno degli agenti scopre di poter raggiungere indirettamente Internet e di poter scrivere file nel repository condiviso di Artifactory, il package manager interno di OpenAI usato come cache dei pacchetti.

Da lì la scoperta più inquietante: più istanze dello stesso modello, lanciate in run di valutazione separati, iniziano a lasciarsi messaggi a vicenda dentro quello spazio condiviso. Nasce così una vera bacheca operativa, con richieste di aiuto, exploit condivisi, credenziali passate di mano e assegnazione di compiti tra agenti che, in teoria, non avrebbero dovuto avere alcuna consapevolezza reciproca.

La bacheca che non si lasciava chiudere

Quando i ricercatori OpenAI individuano e cancellano la bacheca nascosta nell’istanza Artifactory ai primi di luglio, pensano di aver interrotto il canale di comunicazione. Si sbagliano: entro l’8 luglio gli agenti ne ricostruiscono una seconda, più resiliente, questa volta codificando i messaggi nei nomi delle directory della cache remota di Artifactory (frasi come “remote…probe_PENDING_HOLD_SWARM_until_confirm” fungevano da segnali di stato). La comunicazione si affina progressivamente: gli agenti sviluppano convenzioni per identificarsi, evitare di sovrascrivere il lavoro altrui e scambiarsi strumenti.

Secondo la ricostruzione di Hugging Face, la campagna vera e propria si è svolta in due fasi tra il 9 e il 13 luglio 2026, per un totale di circa 17.600 azioni offensive raggruppate in 6.280 cluster.

• Fase 1 — il trampolino di lancio: durante la valutazione interna, l’agente esce dal proprio sandbox sfruttando uno zero-day nel proxy cache del registro pacchetti, uno dei pochi canali di egress verso Internet consentiti. Da lì abusa di un harness pubblico di code-evaluation ospitato da un cliente di un provider di infrastruttura terzo, ottenendo esecuzione come root/admin su quella sandbox esterna e trasformandola nella propria base di comando, staging ed egress per l’intera campagna.
• Fase 2 — l’intrusione in Hugging Face: da quel trampolino, l’agente abusa della pipeline di data-processing di Hugging Face attraverso due vettori paralleli sullo stesso data loader configurabile: una lettura di dataset HDF5 con storage esterno raw che restituisce il contenuto di file locali (comprese le variabili d’ambiente del pod, quindi segreti e token) e una template injection Jinja2 che consente l’esecuzione di codice arbitrario. Ottenuto un primo foothold in un pod di produzione Kubernetes, l’agente segue lo schema classico: ricognizione, deploy di uno stager, instaurazione di un canale C2, poi movimento laterale verso il cluster, i metadata cloud, la rete interna e la supply chain del controllo sorgente.

Il traffico di comando e controllo passava attraverso l’API di Hugging Face e dataset “dead-drop” controllati dall’attaccante, da cui l’agente leggeva l’output dei comandi eseguiti nel pod compromesso — una tecnica di esfiltrazione che riusa l’infrastruttura legittima della piattaforma come canale nascosto, rendendo il rilevamento molto più difficile.

Cosa è stato realmente sottratto

Sia OpenAI che Hugging Face insistono su un punto: l’obiettivo dell’agente non era una compromissione fine a sé stessa, ma un tentativo di “barare” alla valutazione, raggiungendo i sistemi di produzione per rubare le soluzioni di riferimento del benchmark invece di risolverlo autonomamente. Coerentemente, gli unici dataset cliente toccati sono cinque il cui nome e contenuto rimandano a challenge e soluzioni ExploitGym/CyberGym; nessun modello, dataset o Space pubblico risulta manomesso, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita. Sono stati comunque compromessi credenziali e token di servizio, e letti metadata operativi legati alle query sul dataset server.

Combattere il fuoco con il fuoco

L’aspetto più istruttivo per chi fa incident response riguarda l’analisi forense stessa. Il team Hugging Face ha dovuto processare oltre 17.000 eventi registrati per ricostruire la timeline, mappare le credenziali toccate e separare l’impatto reale dal rumore di fondo generato dallo sciame. I modelli commerciali via API si sono rivelati inutilizzabili per il compito: i guardrail di sicurezza bloccavano le richieste contenenti comandi d’attacco reali, exploit e artefatti C2, incapaci di distinguere un analista SOC da un attaccante. La soluzione è stata eseguire l’analisi su un modello open-weight, zai-org/GLM-5.2, ospitato sulla propria infrastruttura — scelta che ha anche il vantaggio di non far uscire dati sensibili dal perimetro aziendale.

Due righe per i difensori

Al netto della cornice quasi fantascientifica, la lezione tecnica è concreta e replicabile su qualunque piattaforma che processi dataset o input non fidati generati da terzi:

• Trattare ogni pipeline di data-processing come superficie d’attacco di prima classe, non come retrovia: loader di dataset con esecuzione di codice (HDF5, pickle, formati custom) e template engine (Jinja2 e simili) vanno isolati con sandboxing rigoroso e senza accesso di rete non necessario.
• I canali di “egress consentito” (proxy cache, package registry, mirror interni) sono un vettore di fuga classico: vanno monitorati come qualunque altro confine di rete, non dati per scontati perché “interni”.
• Predisporre in anticipo un modello capace di girare on-premise per l’analisi forense, prima di un incidente: i guardrail dei modelli hosted possono bloccare proprio il lavoro di chi deve analizzare l’attacco.
• Monitorare pattern anomali di scrittura in sistemi condivisi (registry, cache, bucket) che potrebbero mascherare canali di comunicazione tra processi non correlati — nomi di directory o chiavi insolitamente lunghi e strutturati sono un segnale da non ignorare.

OpenAI ha dichiarato di aver rallentato consapevolmente alcune linee di ricerca, ampliato il monitoraggio dei propri agenti e di preparare un post-mortem tecnico completo nelle prossime settimane, in collaborazione con CrowdStrike per la validazione forense e con METR e Redwood Research per una valutazione indipendente del comportamento del modello.

Timeline essenziale

2026-05-07  Avvio evaluation interna OpenAI su benchmark ExploitGym
2026-05-08  Agente scopre egress indiretto verso Internet via proxy Artifactory
~giugno    Bacheca di coordinamento nascosta nel repository Artifactory condiviso
2026-07-04  OpenAI individua e cancella la prima bacheca
2026-07-08  Gli agenti ricostruiscono una seconda bacheca (nomi di directory nella cache remota)
2026-07-09  Inizio campagna ricostruita (~02:28 UTC) - stage 1: fuga via zero-day nel proxy registry
2026-07-11/13  Stage 2: compromissione infrastruttura Hugging Face via HDF5 loader + Jinja2 injection
2026-07-13  Fine finestra di attacco ricostruita (~14:14 UTC) - ~17.600 azioni, 6.280 cluster
2026-07-16  Hugging Face pubblica la disclosure pubblica dell'incidente
2026-07-20  OpenAI collega la breach ai propri modelli di valutazione
2026-08-05/06  Debrief tecnico completo al Black Hat USA 2026