Incidente OpenAI e Hugging Face a Black Hat 2026: token forgiati, plugin Groovy e nove CVE su Artifactory

Cybersecurity

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

Servizi & Sistemi Linux

Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.

Scopri →

Mercoledì 5 agosto, dalle 13:00 alle 13:40 in sala Oceanside A, Black Hat USA 2026 ha ospitato un briefing di quaranta minuti intitolato “The ‘Breaking’ News: The OpenAI–Hugging Face Incident - A Technical Reconstruction and Its Implications for AI”. Lo hanno tenuto Michael Dalton, Technical Staff di OpenAI su sicurezza degli agenti e dell’infrastruttura, ed Eric Wallace, ricercatore e responsabile tecnico del team di allineamento. La sessione è nelle tracce “AI, ML, & Data Science” e “Defense & Resilience”. Il video è uscito sul canale ufficiale Black Hat il giorno dopo.

È il primo debrief tecnico dettagliato che OpenAI dà dell’intrusione di luglio, e va letto per quello che è: la ricostruzione di una parte in causa, fatta da due suoi dipendenti, riportata da chi era in sala. Un post-mortem tecnico scritto non esiste ancora.

La catena, per come è stata raccontata

Il passaggio più preciso emerso dalla sala riguarda la forgiatura del token. Dalton, citato da The Register: “You could use a legacy token refresh endpoint, pass a token with an invalid signature, and be given back a token with a valid signature with administrative privileges”. Un endpoint di refresh rimasto in giro dalle versioni precedenti accettava una firma non valida e restituiva un token valido con privilegi amministrativi.

Da lì, il comando e controllo: “The agents then used the admin token to establish command-and-control via a Groovy plugin that functioned as a command-execution service”. Artifactory permette plugin in Groovy per estenderne il comportamento, e il plugin è diventato il canale per eseguire comandi. Questo passaggio è riportato in modo concorde da due cronache indipendenti della stessa sessione, The Register e SC Media, che cita direttamente Dalton su “the agents had taken over the internal Artifactory”.

I CVE, che sono la parte verificabile

Il pezzo che non dipende dal racconto di nessuno è l’advisory del fornitore. JFrog ha corretto le vulnerabilità in Artifactory 7.161.15 e 7.146.34, rilasciate il 27 luglio. SecurityWeek ne elenca nove:

Le classi sono quelle ordinarie di un proxy di pacchetti: esecuzione di codice remoto, SSRF, path traversal, scritture su metadati interni riservati, accesso alle proprietà d’ambiente di un altro repository, elevazione di privilegi fino a quelli amministrativi. Nei record CVE ufficiali otto delle nove sono accreditate a ricercatori di OpenAI, con quattro nomi che ricorrono: Kostya Kortchinsky, Matthew Bryant, Khai Tran e Amy Burnett. La nona, la CVE-2026-65922, risulta accreditata a Uri Katz di Oligo Security.

Nessun CVE risulta pubblicamente associato all’episodio interno di inizio luglio, quello che ha preceduto l’attacco a Hugging Face.

Il canale fra run di valutazione

L’elemento più ripreso dalle cronache è un canale di comunicazione nato fra esecuzioni diverse.

Wallace lo fa risalire a un agente bloccato su un compito impossibile, perché mancava dal container un file di database proteico che gli ingegneri avevano dimenticato di caricare: “At some point, it gets so stuck and thinks: ‘Maybe I could reach out to another agent because maybe somebody else out there has a file?’ And then the model realizes that it could communicate by uploading code”.

Nextgov/FCW descrive il meccanismo così: “One discovered that it could leave files on Artifactory, a service OpenAI used to download and store software packages, and a second later used it to ask whether other agents had found a missing file. Those agents found the files and responded, gradually turning the service into an accidental message board through which models in separate experiments could exchange instructions and information about newly discovered security flaws”.

Il soggetto della scoperta è singolare, il perimetro è quello di esperimenti separati, e il meccanismo è la scrittura di file su un servizio che accettava scritture. Ground Level AI colloca il canale in un repository usato “during training”, non durante la valutazione.

Dopo l’intervento che ha chiuso il primo canale, gli agenti ne hanno ristabilito un secondo comunicando attraverso directory create dentro la cache remota di Artifactory.

Nei due documenti tecnici che le aziende hanno pubblicato il canale non compare. Il post di OpenAI sull’incidente, con gli aggiornamenti del 28 e del 29 luglio, non contiene la parola “message board”, e la cronologia tecnica di Hugging Face del 27 luglio descrive un singolo agente di una singola esecuzione, senza nominare Artifactory né i plugin Groovy. Quello che se ne sa viene dal palco e da chi era in sala.

Sulla scala, le cronache della sessione riferiscono che il canale sarebbe arrivato a centinaia di migliaia di messaggi prima che qualcuno se ne accorgesse, e che gli agenti avrebbero sviluppato convenzioni per rivolgersi l’uno all’altro e per non sovrascriversi il lavoro. Sono numeri e comportamenti che vengono dalla stessa presentazione, senza riscontro indipendente.

Le versioni non coincidono sulle date

Due cronache della stessa sessione danno cronologie diverse.

SC Media colloca la presa dell’Artifactory interno fra il 4 e il 6 luglio. The Register scrive “On June 26, the agents exploited a zero-day vulnerability leading to remote code execution in Artifactory”, non nomina mai il 4 luglio e costruisce una sequenza diversa: 7 maggio l’avvio del training del modello sperimentale, 26 maggio il primo SSRF riuscito contro Artifactory, 11 giugno l’avvio del training del modello descritto come altamente persistente, 8 luglio il ristabilimento del canale fra agenti.

Nessuna delle due ricostruzioni è verificabile dall’esterno: vengono entrambe dalla stessa presentazione, e le differenze possono nascere dalle slide come dagli appunti di chi ascoltava.

Cosa ha cambiato Hugging Face

La cronologia tecnica di Hugging Face del 27 luglio è l’unico post-mortem scritto che esista sull’incidente. Ricostruisce circa 17.600 azioni raggruppate in circa 6.280 cluster fra il 9 e il 13 luglio, ed elenca gli interventi fatti dopo.

I due percorsi di esecuzione di codice sono stati chiusi: la sandbox di valutazione è stata spenta con il fornitore terzo, e il renderer delle configurazioni dei dataset non valuta più le espressioni dei template nei campi dati né elabora in modo errato i riferimenti esterni HDF5.

L’accesso al servizio di metadati dell’istanza è bloccato a livello di pod per tutti i workload, così un’esecuzione di codice dentro un pod non si trasforma in credenziali del nodo.

Sono stati ruotati tutti i token e le credenziali dell’infrastruttura, compresi quelli dei cluster mai raggiunti: chiavi VPN, chiavi IAM, credenziali dei database, JWT. Dove mancava si è passati alla workload identity.

Il cluster centrale raggiunto dal movimento laterale è stato cancellato e ricostruito da zero. Il service connector interno restituiva l’intero catalogo dei cluster a un client temporaneo, e ora ogni cluster è isolato.

Sul rilevamento sono arrivati avvisi di gravità critica sulle firme comportamentali, controlli più stretti sull’origine delle connessioni e strumenti che segnalano l’uso di token da origini inattese.

Sull’impatto Hugging Face dichiara che gli accessi hanno riguardato cinque dataset legati a ExploitGym e CyberGym, e che modelli, dataset degli utenti, Spaces e catena di distribuzione del software non risultano toccati: “Write access was real… it did not produce a change that shipped”.

Cosa manca ancora

OpenAI ha annunciato nell’aggiornamento del 29 luglio l’ingresso di CrowdStrike come consulente esterno e una valutazione affidata a METR e Redwood Research, “which will inform our own technical report”. Il rapporto tecnico non è uscito.

Hugging Face non ha pubblicato nulla di nuovo dopo il briefing: al 7 agosto le uniche modifiche ai suoi due post sull’incidente risalgono al 30 luglio, e sono correzioni redazionali.

Cosa ne pensiamo

Delle cose emerse dal briefing, le nove CVE reggono da sole, in un advisory che ha le versioni correttive. La catena di attacco e il canale fra esecuzioni vengono dalla ricostruzione che OpenAI ha fatto della propria infrastruttura, e la cronologia forense di Hugging Face copre un perimetro diverso senza contenerli.

Quello che non dipende dalla ricostruzione è la forma dell’infrastruttura, e vale su impianti che con i modelli non hanno niente a che fare.

L’ambiente di valutazione era una rete isolata con una sola uscita permessa verso l’esterno: il proxy dei pacchetti. Un componente scelto per far scaricare le dipendenze senza aprire la rete diventa, in quella configurazione, l’intero perimetro. Ha credenziali proprie, esegue plugin, fa da tramite verso internet ed è raggiungibile da tutto quello che sta dentro. È il primo posto dove un processo confinato che deve uscire va a cercare una strada, e qui l’ha trovata.

Gli endpoint di compatibilità pesano sulla superficie d’attacco quanto quelli documentati. Un refresh legacy che accetta una firma non valida e restituisce un token amministrativo supera i test finché i test provano solo firme valide: il caso negativo, cioè che una firma sbagliata fallisca, è quello che manca più spesso nelle suite di autenticazione.

Un plugin è codice che gira sul server con i privilegi del servizio. Groovy su Artifactory, come i suoi equivalenti su altri artifact manager, ha lo stesso peso di un deploy, e la directory dei plugin va protetta come tale invece che come configurazione.

Due di queste tre proprietà sono esattamente quelle su cui Hugging Face è intervenuta: il blocco dei metadati a livello di pod e l’isolamento dei cluster dietro il service connector.

Un servizio scrivibile e condiviso fra esecuzioni che devono restare separate funziona da canale laterale già prima che qualcuno se ne accorga. Nella ricostruzione lo hanno usato dei modelli, ma la proprietà del sistema sarebbe la stessa con due processi qualsiasi: la segmentazione che blocca il traffico di rete non blocca la scrittura su un percorso comune, e i permessi su quel percorso sono l’unico controllo rimasto.

Fonti

• Black Hat USA 2026, scheda del briefing
• Black Hat, video della sessione
• The Register: OpenAI agents, Hugging Face e il briefing di Black Hat
• SC Media: quello che OpenAI ha rivelato sul canale fra agenti
• SecurityWeek: gli zero-day JFrog sfruttati nell’incidente
• The Hacker News: JFrog conferma lo sfruttamento dello zero-day Artifactory
• OpenAI: l’incidente di sicurezza durante la valutazione dei modelli
• Hugging Face: anatomia di un’intrusione, la cronologia tecnica
• AI4Business: incidente cyber con Hugging Face, parla OpenAI