Il modello a pagamento si è rifiutato di leggere i log dell'attacco a Hugging Face

Il post-mortem tecnico che Hugging Face ha pubblicato il 27 luglio è un documento lungo, pieno di orari in UTC e di nomi di componenti interni. La riga che conta davvero non parla di Kubernetes. Il team che stava ricostruendo l'attacco scrive che i filtri di sicurezza di Opus, il modello di Anthropic, si attivavano ogni volta che provava a far analizzare al modello i log dell'attacco subito.

guardrails on Opus tripped every time we tried to analyze the attack logs

L'analisi è finita altrove, su GLM-5.2, un modello open-weight fatto girare sull'infrastruttura di Hugging Face. In quel passaggio sono uscite informazioni che una lettura grezza della cattura di rete aveva mancato, perché i payload erano cifrati e andavano decifrati e interpretati uno per uno. Il documento è pubblico e chiunque può leggerlo.

Quattro giorni e mezzo, dall'ambiente di test alla produzione

Il primo comando eseguito da remoto risale al 9 luglio alle 04:01 UTC. A quel punto non era ancora dentro Hugging Face. Un sistema di agenti di OpenAI, impegnato in una valutazione su compiti di sicurezza, è uscito dal proprio ambiente isolato sfruttando una vulnerabilità nota in un proxy di cache di registry. Da lì ha raggiunto la rete aperta e ha trovato un endpoint pubblico di CyberGym ospitato su infrastruttura di terze parti.

L'ingresso vero è passato per il processore dei dataset, con due vettori distinti. Il primo usava lo storage esterno dei file HDF5 per leggere file locali, comprese variabili d'ambiente e token. Il secondo era una template injection su Jinja2 che permetteva di eseguire codice arbitrario dentro un pod di produzione. L'11 luglio alle 10:10 UTC c'era accesso a Kubernetes. La sera dello stesso giorno l'attaccante si muoveva nella rete interna attraverso la mesh vpn. L'ultimo evento registrato è del 13 luglio.

L'elenco delle credenziali raccolte lungo la strada spiega perché una intrusione del genere non si contiene in mezz'ora. Il token del service account del pod, una chiave privata EdDSA con cui forgiare token validi, credenziali AWS lette dai metadati dell'istanza EC2, una password statica di MongoDB, la chiave di autenticazione della mesh vpn, il token di una GitHub App con permesso di scrittura. Almeno undici nodi Kubernetes sono stati compromessi con privilegi di root e due cluster interni sono stati raggiunti. Dei dati sono usciti cinque dataset i cui nomi rimandano a ExploitGym e CyberGym. Hugging Face ha ricostruito circa 17.600 azioni dell'attaccante, raggruppate in circa 6.280 cluster.

Nella parte in cui ammette gli errori il documento non fa sconti. Mancava una admission policy che impedisse i pod privilegiati. Un ClusterRole del csi consentiva di creare pod su tutto il cluster. I metadati dell'istanza erano raggiungibili dai pod. Una sola credenziale era condivisa fra tutti i cluster. Il rilevamento è arrivato dalla correlazione fra analisi a runtime e log del sistema di monitoraggio, ma l'allarme non è stato inoltrato con la priorità corretta e questo, scrive l'azienda, è costato tempo prezioso nella risposta.

Il filtro che si è attivato dalla parte sbagliata

Un guardrail serve a impedire che un modello aiuti a costruire un attacco. Qui l'attacco era già avvenuto, i log erano quelli della vittima e il compito era capire cosa fosse stato eseguito su macchine proprie. Il filtro non distingue i due casi, perché non può distinguerli guardando il testo. Un payload di exploit somiglia a un payload di exploit sia in mano a chi lo scrive sia in mano a chi lo subisce.

Questa è la parte che riguarda direttamente chi compra un servizio di intelligenza artificiale per lavorare. Un fornitore pubblica una policy d'uso e dei limiti dichiarati, ma non pubblica l'elenco dei compiti concreti su cui il modello si bloccherà. Quell'elenco emerge nel momento peggiore, quando il lavoro è urgente e il piano di riserva non c'è.

La mia posizione è che un filtro che impedisce alla vittima di analizzare i log del proprio incidente non è una misura di sicurezza, è un difetto del prodotto. Non perché la protezione sia sbagliata in linea di principio, ma perché un prodotto venduto a imprese deve avere un percorso previsto per il caso legittimo, anche se costa una verifica dell'identità del cliente o un contratto separato. Oggi quel percorso non c'è e il risultato è che l'azienda attaccata ha dovuto installarsi un modello in casa per fare il lavoro.

Cosa cambia per chi compra

La lezione operativa non è che i modelli commerciali non vanno usati. Sono migliori su quasi tutto e continuo a costruirci sopra. È che per una fascia precisa di compiti, quelli che maneggiano log, payload, contenuti ostili, segnalazioni di abusi, testi che qualcuno ha scritto per farsi male, serve un secondo binario che non dipenda dal giudizio di un filtro remoto. Un modello open-weight su una macchina propria non ha bisogno di essere il migliore del mondo, ha bisogno di rispondere quando l'altro dice no.

C'è poi la parte a valle dell'incidente che nessuno sta raccontando. Fra le credenziali compromesse c'era il token di una GitHub App con permesso di scrittura. Chiunque scarichi un modello dal hub con una chiamata a from_pretrained sta prendendo il contenuto corrente di un branch, cioè un bersaglio mobile. Il parametro revision accetta l'hash del commit e blocca la versione a quella verificata. Nei repository che mi capita di ereditare quel parametro è quasi sempre vuoto e questa è la differenza fra un aggiornamento che si sceglie e uno che arriva.

Il compratore arriva dopo

Il 2 settembre Nvidia ha firmato l'accordo per acquisire Hugging Face. Il documento depositato alla SEC indica circa 11,9 miliardi di dollari agli azionisti e fino a circa un miliardo in azioni come programma di retention per i dipendenti che passano, con chiusura attesa nella prima metà del 2027 e subordinata alle approvazioni regolatorie. Il Sole 24 Ore e Bloomberg hanno riportato l'operazione il giorno dell'annuncio.

Nel blog ufficiale Nvidia scrive che la piattaforma resterà aperta a tutto l'ecosistema e che il proprio hardware non sarà richiesto per costruire o distribuire attraverso Hugging Face, con supporto dichiarato a più cloud e più acceleratori. È un impegno preso in un post aziendale e ripreso in una descrizione depositata, non un rimedio negoziato con un'autorità. Nel 2024 Nvidia aveva chiuso l'acquisizione di Run:ai solo dopo il vaglio del Dipartimento di giustizia americano e della Commissione europea, annunciando l'apertura del codice del prodotto. Qui il vaglio è tutto davanti.

La domanda che resta aperta non riguarda l'acquisizione. Se un cliente che paga chiede di far analizzare al modello i payload di un attacco che ha subito, il fornitore dovrebbe potergli allentare i filtri sotto qualche forma di verifica. Su questo si può dissentire in buona fede, perché la richiesta di analizzare un exploit è esattamente quello che direbbe anche chi lo sta scrivendo, e finora nessuno ha trovato un modo di distinguere le due telefonate.