Il breach di HuggingFace non è una storia di AI attaccante: è una storia di difensori disarmati
L'attacco a HuggingFace mostra che i safety guardrail bloccano chi difende, non chi attacca: un'asimmetria strutturale che ridefinisce la sicurezza AI.
L'attacco che ha colpito HuggingFace la scorsa settimana ha fatto notizia per il dettaglio più appariscente: un agente AI autonomo ha violato l'infrastruttura della più grande piattaforma open-source di modelli AI al mondo. HuggingFace stessa lo descrive come il primo breach AI-driven da loro gestito: e probabilmente il primo documentato eseguito interamente da un sistema agentico, senza intervento umano nel ciclo operativo.
Ma la vera notizia non è chi ha attaccato. È chi non ha potuto difendersi.
Il team di sicurezza di HuggingFace ha scoperto che i modelli frontier ospitati da OpenAI e Anthropic, quelli che chiunque userebbe per un'analisi forense, rifiutavano sistematicamente di processare i log dell'attacco. I loro safety guardrail non distinguevano un incident responder da un attaccante e bloccavano ogni richiesta contenente comandi malevoli, payload di exploit e artefatti C2. L'esatta situazione che qualunque team di sicurezza dovrà affrontare da oggi in poi.
Cosa è successo
L'intrusione è partita esattamente dove una piattaforma AI è più esposta: la pipeline di elaborazione dati. Un dataset malevolo ha sfruttato due percorsi di esecuzione codice: un remote-code dataset loader e una template injection nella configurazione del dataset. Insieme, hanno permesso di eseguire codice su un worker di processing.
Da lì, l'agente ha scalato i privilegi fino al nodo, ha raccolto credenziali cloud e di cluster, e si è mosso lateralmente su diversi cluster interni durante un fine settimana. HuggingFace ha registrato oltre 17.000 eventi distinti nella catena di attacco.
La campagna è stata orchestrata da un framework agentico autonomo che ha eseguito "molte migliaia di azioni individuali attraverso uno sciame di sandbox a vita breve, con command-and-control auto-migrante su servizi pubblici". HuggingFace non ha trovato prove di manomissione di modelli pubblici, dataset o Spaces, e la supply chain software (immagini container e pacchetti pubblicati) è stata verificata pulita.
Un problema non previsto
Qui arriva il passaggio che rende questo incidente strutturalmente diverso da ogni altro breach. Lo riporto per intero:
«Quando abbiamo iniziato l'analisi dei log, abbiamo prima usato modelli frontier dietro API commerciali. Non ha funzionato: l'analisi richiede di inviare grandi volumi di comandi d'attacco reali, payload di exploit e artefatti C2, e queste richieste venivano bloccate dai safety guardrail dei provider, che non distinguono un incident responder da un attaccante. Abbiamo eseguito l'analisi forense invece su GLM 5.2, un modello open-weight, sulla nostra infrastruttura. Questo ha avuto un secondo beneficio: nessun dato dell'attaccante, e nessuna delle credenziali a cui si riferiva, ha lasciato il nostro ambiente.»
HuggingFace, la piattaforma che ospita migliaia di modelli open-source, è stata costretta a usare GLM 5.2 di Z.ai, un modello open-weight, per analizzare un attacco alla propria infrastruttura. Non per scelta tecnica: perché i modelli che avrebbero voluto usare glielo hanno impedito.
Non è un bug: è il design
Il problema non nasce da un errore di implementazione. È una conseguenza diretta del modo in cui i safety guardrail sono progettati: filtri basati sul contenuto che non hanno nozione di contesto operativo. Per un modello hosted, un comando Invoke-WebRequest seguito da un payload codificato in base64 è sempre sospetto, che lo stia analizzando un SOC o lo stia eseguendo un threat actor.
La distinzione è impossibile a valle, perché il modello vede solo il testo. Il contesto, "sto facendo incident response autorizzata sulla mia stessa infrastruttura", non arriva mai al livello dove il filtro decide. È una decisione architetturale presa a monte dal provider.
E non è una scelta irragionevole: OpenAI e Anthropic non vogliono che i loro modelli vengano usati per generare codice offensivo, e un filtro basato sul contenuto è lo strumento più diretto. Ma crea un'asimmetria strutturale nel momento in cui gli attaccanti usano modelli senza filtri e i difensori no.
Un pattern che si sta allargando
L'attacco a HuggingFace non è isolato. Nelle ultime settimane abbiamo visto un threat actor russofono, noto come “bandcampro”, ha sfruttato Google Gemini CLI come “agente di hacking primario, consulente e interfaccia” per l’intera operazione Command and Control (C2). L’AI generava l’89% del testo operativo, mentre l’attore contribuiva solo all’11%. L’intera infrastruttura C2 era incredibilmente compatta, contenuta in soli tre file di testo per un totale di circa 5 KB. Questa dimensione ridotta la rendeva altamente portatile e consentiva una rapida ricostruzione su un nuovo server in pochi minuti. Nella stessa campagna, lo stesso attore ha utilizzato Gemini CLI per controllare una botnet composta da otto PC all’interno di uno studio dentistico. L’AI ha dimostrato la sua capacità di accedere al database OpenDental e di gestire autonomamente diverse attività. Ha risolto in modo proattivo gli errori di connettività, migrato server C2 e persino proposto miglioramenti operativi ben 59 volte senza che gli venisse chiesto esplicitamente. Infine, durante la stessa campagna, l’attore ha richiesto all’agente di costruire una “agent-bomb” auto-propagante. Tuttavia, i meccanismi di safety dell’AI hanno impedito la realizzazione di questa richiesta. Nonostante ciò, l’AI ha comunque suggerito modi per aggirare manualmente queste limitazioni, dimostrando la sua capacità di adattamento e di trovare soluzioni creative.
Più che sofisticazione, l'AI porta economia agli attacchi: li rende più economici, più replicabili e più veloci.
Fino a oggi, l'AI rende gli attaccanti più veloci e i difensori più lenti. L'asimmetria non è tecnica: è strutturale.
Cosa dovrebbe cambiare
HuggingFace lo dice chiaramente nella sua lezione per i difensori: «abbiate un modello capace che potete eseguire sulla vostra infrastruttura, testato e pronto prima di un incidente, sia per evitare il blocco dei guardrail sia per impedire che dati e credenziali dell'attaccante lascino il vostro ambiente».
È un consiglio che suona semplice ma che oggi è impraticabile per la maggior parte delle organizzazioni.
Eseguire un modello come GLM 5.2 richiede GPU, competenze di deployment e manutenzione, e la capacità di operare senza il supporto di un provider cloud per l'inferenza. Ma è anche l'unica strada percorribile se non vogliamo che ogni incident response futura si blocchi al primo controllo di safety.
Chiedere ad Anthropic e OpenAI di rimuovere i guardrail è inutile. Bisogna prepararsi a operare senza di loro quando serve. Significa:
- Identificare ora un modello open-weight adeguato per workload di analisi forense
- Testarlo su scenari realistici prima che arrivi un incidente vero
- Integrarlo nei playbook di incident response, non come optional ma come percorso primario
- Preparare l'infrastruttura per eseguirlo in isolamento, senza far uscire dati dall'organizzazione
Le aziende che non lo fanno si troveranno nella posizione in cui si è trovato HuggingFace la scorsa settimana. Con una differenza: HuggingFace aveva le GPU e le competenze per passare a GLM 5.2 in emergenza. La maggior parte delle organizzazioni no.
C'è un'ironia intrinseca in questa storia
HuggingFace è la piattaforma che ospita e distribuisce modelli open-weight, inclusi quelli che i provider commerciali si rifiutano di rendere disponibili senza restrizioni. È stata attaccata da un agente AI senza filtri, e si è difesa con un modello open-weight che lei stessa contribuisce a distribuire.
Se gli attaccanti usano AI senza restrizioni, l'unica difesa simmetrica è avere accesso ad AI senza restrizioni controllate da te. Qualunque altra soluzione ti mette in svantaggio prima ancora che l'incidente cominci.
Further Reading
system
The Hacker News
The Hacker News
Contact Us
