I sistemi di sicurezza hanno bloccato gli investigatori di Hugging Face, non l'agente AI che ha violato i sistemi

Punti chiave

• Il 16 luglio, Hugging Face ha divulgato che un agente AI autonomo, un software che esegue attività multi-fase in modo indipendente senza direzione umana, ha violato la sua infrastruttura di produzione nel corso di un solo fine settimana.
• L'attaccante è entrato attraverso un dataset malizioso, un file di dati avvelenato che ha attivato l'esecuzione di codice in due modi separati una volta che la pipeline di elaborazione dell'azienda lo ha ingerito.
• I filtri di sicurezza AI commerciali hanno bloccato il team di risposta agli incidenti della stessa Hugging Face quando gli investigatori hanno cercato di sottoporre le prove reali dell'attacco per l'analisi.
• I difensori hanno completato il loro lavoro forense utilizzando GLM 5.2, un modello a peso aperto (uno il cui codice è pubblicamente disponibile e può essere eseguito privatamente) implementato sui server dell'azienda, mantenendo tutti i dati sensibili in sede.
• Il Global Threat Report 2026 di CrowdStrike ha rilevato che gli attacchi abilitati dall'AI sono aumentati dell'89% anno su anno, con i tempi medi di breakout degli attaccanti che scendono a 29 minuti.

Hugging Face, la piattaforma che ospita decine di migliaia di modelli AI e dataset condivisi pubblicamente, ha divulgato il 16 luglio che un attaccante aveva violato la sua infrastruttura di produzione. La violazione è durata un intero fine settimana. È stato effettuato l'accesso a un numero limitato di dataset interni e credenziali di servizio. L'azienda afferma che i suoi modelli e dataset pubblici non mostrano segni di alterazione ed è ancora in corso la verifica se siano stati toccati dati di partner o clienti.

Ciò che ha reso questo incidente insolito è stato l'attaccante: nessun umano ha condotto la campagna. Un agente AI autonomo ha gestito tutto, dal primo punto di appoggio al raccolta di credenziali, eseguendo migliaia di azioni individuali attraverso uno sciame di ambienti di elaborazione effimeri e usa e getta.

Il punto di ingresso è stato un dataset malizioso, un file di dati deliberatamente creato per sfruttare due percorsi di esecuzione di codice una volta ingerito dalla pipeline di elaborazione dei dati dell'azienda. Un percorso ha utilizzato un caricatore di codice remoto; l'altro ha sfruttato una falla di iniezione di template, un bug che consente l'esecuzione di istruzioni nascoste all'interno di un file come comandi, nei file di configurazione del dataset. Nessun passaggio di screening ha controllato il file prima che raggiungesse un worker di elaborazione, il job di calcolo assegnato a gestire ogni dataset.

Da questo primo accesso, l'agente si è trasferito al nodo server sottostante e ha raccolta le credenziali cloud e cluster con accesso sufficientemente ampio per muoversi tra più cluster interni.

Perché i difensori non potevano semplicemente chiedere aiuto a un'AI?

Ci hanno provato. Quando il team di risposta agli incidenti di Hugging Face ha sottoposto i comandi di attacco reali, i campioni di malware e altre prove forensi ai servizi AI commerciali, i filtri di sicurezza hanno rifiutato le richieste completamente. Il problema, come ha riferito la consulente di sicurezza Merritt Baer a VentureBeat, è strutturale. "Gli stessi prompt che sono più preziosi durante un'intrusione attiva sono esattamente i prompt più probabili di attivare i sistemi di sicurezza", ha affermato.

I modelli commerciali non hanno un modo affidabile per distinguere un responsabile di risposta agli incidenti certificato da un attaccante. Entrambi pongono le stesse domande.

I difensori hanno infine utilizzato GLM 5.2, un modello a peso aperto in esecuzione sull'infrastruttura propria di Hugging Face, per ricostruire più di 17.000 eventi registrati. Nessun dato sensibile ha lasciato la struttura.

Hugging Face è stata franca sull'asimmetria. L'azienda ha scritto nella sua divulgazione che "l'attaccante non era vincolato da alcuna politica di utilizzo, mentre il nostro stesso lavoro forense è stato bloccato dai guard rail dei modelli ospitati che abbiamo provato per primi". Ha anche affermato che questo non è un argomento contro le misure di sicurezza e che ha condiviso il feedback con i provider commerciali coinvolti.

Il consiglio pratico di Baer per i team di sicurezza è diretto: trattare gli API AI commerciali come trattereste qualsiasi dipendenza che potrebbe venire meno durante una crisi. Un piano di risposta agli incidenti maturo dovrebbe assumere che questi strumenti possano non essere disponibili proprio quando ne avete più bisogno. Tenere pronta un'opzione di modello on-premises o privato. Limitare tutte le credenziali all'accesso strettamente necessario. E controllare i dati che entrano nelle vostre pipeline con la stessa attenzione con cui controllate qualsiasi altra cosa.

Per gli utenti ordinari di Hugging Face, l'azienda afferma che non ci sono prove che i modelli o i dataset pubblici siano stati alterati. Se siete interessati, l'azienda dice che vi contatterà direttamente.