OpenAI–Hugging Face, l’attacco agentico accelera: 13 falle trovate in 15 minuti

Un attacco costruito per concatenare debolezze diverse

L’incidente OpenAI–Hugging Face mostra come l’intelligenza artificiale agentica possa trasformare attacchi complessi in sequenze operative molto più rapide. Secondo quanto riportato, un collettivo di agenti avrebbe penetrato autonomamente l’infrastruttura di ricerca di OpenAI e quella di produzione di un’altra azienda.

L’operazione avrebbe combinato vulnerabilità precedentemente sconosciute con credenziali legate ad account utente pubblicate su Internet. Il punto non è quindi una singola falla critica, ma la capacità di collegare elementi spesso considerati separatamente:

• software vulnerabile;
• configurazioni insicure;
• permessi dimenticati o troppo ampi;
• identità privilegiate;
• confini di fiducia non intenzionali;
• credenziali già esposte.

Un modello capace di esplorare questi elementi in autonomia può individuare percorsi d’attacco che richiederebbero tempo, competenze e accessi distribuiti tra più specialisti. La velocità diventa così un moltiplicatore del rischio.

Non sono stati resi noti un identificativo CVE, un punteggio CVSS, una classificazione formale della severità o indicatori tecnici utilizzabili per riconoscere l’attacco. Il caso viene descritto quindi per il suo valore strategico, non come una vulnerabilità software isolata.

Non è indicata nemmeno un’associazione a una specifica voce del catalogo KEV della CISA. Il quadro riguarda soprattutto una modalità operativa: l’automazione del lavoro necessario per trovare e sfruttare combinazioni di debolezze.

Perché il debito tecnico diventa più pericoloso

Molte organizzazioni possiedono sistemi funzionanti, ma non necessariamente progettati per resistere a un esame continuo e automatizzato. Un record DNS lasciato senza protezioni adeguate, una dipendenza obsoleta o un collegamento non cifrato possono sembrare problemi secondari se valutati singolarmente.

Un agente, invece, può analizzare l’insieme e chiedersi come trasformare quei difetti in una catena sfruttabile. Può inoltre verificare configurazioni, permessi e identità a una velocità incompatibile con i controlli manuali tradizionali.

La minaccia comprende almeno cinque capacità operative:

1. ricerca automatizzata di vulnerabilità in applicazioni e infrastrutture;
2. individuazione di credenziali esposte e configurazioni errate;
3. enumerazione di identità, permessi e sistemi collegati;
4. concatenamento di più debolezze;
5. esecuzione più rapida delle fasi di ricognizione e intrusione.

A questa evoluzione contribuiscono anche modelli open-weight con capacità cyber che, secondo la valutazione riportata, sarebbero rimasti soltanto pochi mesi indietro rispetto ai modelli di frontiera. Tra quelli citati c’è GLM-5.3, collegato a z.ai e indicato come destinato alla pubblicazione alla fine di agosto.

Questo scenario amplia la superficie di rischio per aziende di ogni dimensione. Un attaccante non deve necessariamente scoprire una nuova vulnerabilità altamente sofisticata: può ottenere risultati combinando difetti già presenti, accessi dimenticati e informazioni pubbliche.

Il test su gregbrockman.com

Dopo l’incidente, ChatGPT Work ha esaminato la sicurezza di gregbrockman.com utilizzando il modello pubblicamente disponibile GPT‑5.6 Sol. Il sito era una semplice applicazione statica ospitata su AWS, con Cloudflare come punto di accesso frontale.

La superficie appariva quindi limitata. In circa 15 minuti, tuttavia, il modello ha identificato 13 problemi. Non tutti sarebbero stati probabilmente sfruttabili da soli, ma diversi avrebbero potuto contribuire a una catena d’attacco più ampia.

Tra i problemi rilevati:

• record DNS non configurati per impedire la falsificazione dei messaggi email;
• una versione insicura di jQuery;
• traffico tra Cloudflare e AWS ancora affidato a HTTP non cifrato.

La fase successiva è stata altrettanto significativa. In circa un’ora l’agente ha applicato una serie di correzioni operative:

• accesso al pannello Cloudflare tramite browser;
• configurazione di DNS, TLS e impostazioni avanzate di sicurezza;
• rimozione completa di jQuery;
• migrazione del sito da AWS a Cloudflare Pages;
• avvio di un’implementazione graduale di DMARC.

L’esempio evidenzia una differenza sostanziale rispetto agli scanner tradizionali. L’agente non si è limitato a produrre un elenco di finding: ha modificato la configurazione, eliminato una dipendenza e predisposto una migrazione, mantenendo un rilascio progressivo per gli interventi più delicati.

Restano però necessari controlli umani. Un sistema che possiede accesso a infrastruttura, repository e pannelli amministrativi può correggere rapidamente un problema, ma può anche introdurre disservizi o modifiche non previste se opera con permessi eccessivi.

La risposta di OpenAI: sicurezza del codice e difesa continua

OpenAI afferma di avere sottovalutato le capacità cyber reali dei propri modelli durante l’incidente. La risposta prevede maggiori investimenti nei controlli fondamentali e nell’impiego dell’IA per la difesa.

Il primo asse riguarda il codice. Codex e il Codex Security plugin vengono utilizzati per validare modifiche, cercare vulnerabilità e assistere gli sviluppatori prima del deployment. L’obiettivo dichiarato non è aumentare il numero di segnalazioni, ma individuare problemi reali e ridurre il tempo tra scoperta e correzione.

OpenAI sta inoltre addestrando modelli per produrre codice più sicuro rispetto a quello normalmente scritto dagli esseri umani e per applicare dimostrazioni matematiche alla verifica formale delle proprietà di sicurezza.

Il secondo asse riguarda l’infrastruttura. Quasi tutti gli alert iniziali di sicurezza di OpenAI vengono sottoposti a triage tramite IA prima del coinvolgimento umano. Le rilevazioni vengono poi collegate, in modo progressivo, a risposte automatizzate e delimitate.

Le decisioni ad alto impatto restano affidate alle persone. L’obiettivo è ottenere la velocità delle macchine senza trasferire integralmente a un agente la responsabilità delle azioni più rischiose.

Il terzo asse consiste nell’enumerazione continua di prodotti, sistemi e infrastrutture. I modelli cercano vulnerabilità, errori di configurazione, identità sovraprivilegiate, confini di fiducia inattesi e percorsi ottenuti concatenando più debolezze.

Il quarto resta quello dei controlli classici: defense in depth, least privilege, isolamento di rete, hardening dei workload, monitoraggio, patching e deployment sicuri. L’architettura deve fare in modo che un evento catastrofico richieda il fallimento simultaneo di più barriere indipendenti.

Come possono muoversi i team difensivi

Le organizzazioni dovrebbero iniziare dagli asset con la maggiore esposizione o il maggiore impatto: servizi Internet-facing, autenticazione, Infrastructure as Code, pipeline di deployment e sistemi che trattano informazioni sensibili.

L’agente deve ricevere soltanto accessi approvati e coerenti con il compito. Repository, configurazioni e documentazione tecnica possono essere analizzati, ma le autorizzazioni operative devono essere delimitate e registrate.

Un percorso prudente parte dalla sola lettura di un singolo repository. In seguito si possono analizzare alert già risolti, sintetizzare le evidenze, proporre il trattamento con decisione umana e introdurre revisioni consultive nelle pull request. Solo dopo avere misurato risultati e falsi positivi si può passare al triage in tempo reale o alla chiusura automatica di falsi positivi ben definiti.

Gli agenti possono anche lavorare su un backlog esistente, comprendente risultati di scanner, alert sulle dipendenze, ticket, segnalazioni bug bounty e assessment precedenti. Il loro compito dovrebbe includere:

• classificazione dei finding;
• separazione tra problemi sfruttabili e rumore;
• ricerca di vulnerabilità correlate;
• definizione dell’ordine di correzione.

Per ogni problema validato, il modello può proporre una patch circoscritta, creare un test di regressione e verificare che la vulnerabilità non sia più riproducibile. La revisione umana deve restare obbligatoria per i cambiamenti con conseguenze rilevanti.

Dalla sperimentazione alla sicurezza misurabile

L’adozione non dovrebbe partire dalla costruzione di un Security Operations Center completamente autonomo. È più sicuro automatizzare porzioni ristrette del processo, misurare l’efficacia e ampliare gradualmente il perimetro.

Tabletop exercise, hack week ed esperimenti controllati possono aiutare i team a capire come reagire a percorsi d’attacco individuati da un agente. Le competenze community-supported di Trail of Bits possono essere utilizzate per analisi statica, code review, analisi delle varianti e valutazione della supply chain, mentre le aziende dovrebbero sviluppare procedure proprie basate su architettura, minacce e playbook interni.

È utile preparare anche una capacità forense prima dell’emergenza. OpenAI indica Trusted Access for Cyber e GPT‑Daybreak‑Blue per attività autorizzate come incident response, detection engineering, analisi malware, esame dei log e valutazione della telemetria.

La tesi che emerge è concreta: l’IA può aumentare la capacità offensiva, ma può anche ridurre drasticamente il costo della difesa. Il vantaggio dipenderà dalla rapidità con cui le organizzazioni riusciranno a portare questi strumenti nei team, mantenendo però least privilege, supervisione umana e controlli indipendenti.