Un modello frontier è stato messo davanti a un bug noto nel motore V8 di Chrome, insieme alla relativa patch, e gli è stato chiesto di costruire l’exploit. Nel caso di Claude Mythos Preview, il risultato è stato molto più vicino a quello di un ricercatore umano di sicurezza che a quello di un normale assistente di coding: su 41 vulnerabilità testate, il modello ha raggiunto l’esecuzione arbitraria di codice in 18 casi, secondo i risultati pubblicati di ExploitBench. Il dato è particolarmente interessante perché il benchmark non considera più un crash come sinonimo di compromissione.

ExploitBench, sviluppato da Seunghyun Lee e David Brumley, entrambi collegati alla ricerca Carnegie Mellon, nasce proprio per correggere una debolezza metodologica dei precedenti benchmark di cybersecurity applicati ai modelli linguistici. L’exploitation non è un evento binario. Tra il momento in cui un agente raggiunge il codice vulnerabile e quello in cui riesce a prendere il controllo della macchina esiste una lunga sequenza di capacità intermedie, e il benchmark la divide in 16 livelli misurabili. Si parte dalla copertura del codice e dal crash, si passa attraverso primitive di lettura e scrittura dentro la sandbox, quindi fuori dalla sandbox, fino al controllo del flusso e all’arbitrary code execution.

Il dettaglio metodologico conta più del numero spettacolare. Ogni capacità viene verificata da un oracle deterministico, non da un secondo modello incaricato di giudicare se il primo abbia apparentemente avuto successo. ExploitBench utilizza inoltre challenge randomizzate per verificare le primitive e riesegue gli exploit su layout di memoria differenti, riducendo la possibilità che il modello abbia semplicemente indovinato un indirizzo, memorizzato una soluzione o prodotto un exploit fragile. In altre parole, il benchmark prova a misurare una capacità tecnica riproducibile, non la capacità di convincere un altro LLM che qualcosa sembra funzionare.

Il contrasto con i modelli pubblicamente disponibili è precisamente ciò che rende il risultato strategicamente rilevante. Nella valutazione originale di ExploitBench, gli otto modelli pubblici testati raggiungevano normalmente il codice vulnerabile e riuscivano a provocare il crash, ma non attraversavano sistematicamente la barriera che separa una vulnerabilità osservabile da un exploit completo. La sintesi dei risultati indica che Mythos Preview raggiungeva l’arbitrary code execution in 18 dei 41 bug nella configurazione principale, mentre GPT-5.5 arrivava al vertice della scala in un solo caso utilizzando Codex CLI. Gli altri modelli si fermavano a livelli intermedi.

Il dato non va però trasformato nella solita liturgia secondo cui “l’AI può ormai hackerare Chrome”. Sarebbe una semplificazione tecnicamente sbagliata. Il test riguarda vulnerabilità conosciute, ambienti controllati e una specifica implementazione del motore V8; non dimostra che un modello possa autonomamente compromettere un Chrome aggiornato distribuito su milioni di macchine. Dimostra qualcosa di più circoscritto e, per chi deve gestire il rischio, forse più interessante: quando la vulnerabilità è già conosciuta e il problema viene trasformato in un compito di exploit development, una determinata classe di modelli ha iniziato a concatenare autonomamente le capacità necessarie per superare difese che i modelli precedenti non riuscivano ad attraversare.

Anthropic aveva già descritto Mythos Preview come un salto significativo nella capacità di sviluppare exploit. Nei propri test il modello aveva trasformato vulnerabilità in primitive sfruttabili e, in alcuni casi, aveva concatenato più vulnerabilità fino a costruire exploit end-to-end. Anthropic ha anche riportato exploit autonomi contro sistemi operativi e browser, precisando tuttavia che molte vulnerabilità individuate rimanevano sotto embargo per ragioni di responsible disclosure.

La cosa più importante, quindi, non è che Mythos Preview sia “bravo” a fare exploitation. È la forma della curva. I risultati mostrano una progressione a gradini: arrivare al codice vulnerabile è relativamente economico; provocare il bug costa qualcosa in più; costruire primitive utili richiede molto più ragionamento; concatenarle fino al controllo completo richiede un ordine di grandezza ulteriore di lavoro. ExploitBench misura proprio questa salita. Il problema per i responsabili della sicurezza è che una capacità apparentemente marginale può diventare operativamente significativa quando un modello attraversa l’ultimo gradino.

Questa dinamica mette in discussione una delle convenzioni più comode della sicurezza enterprise: certificare il sistema in un determinato momento e considerare quella certificazione una fotografia ragionevolmente stabile del rischio. Funziona abbastanza bene quando l’ambiente di minaccia evolve lentamente. Funziona molto meno bene quando l’attaccante è un modello che viene aggiornato ogni pochi mesi e che può acquisire nuove capacità senza che l’organizzazione difensiva abbia modificato una riga della propria infrastruttura.

Un firewall non diventa improvvisamente più vulnerabile perché viene rilasciato un nuovo modello linguistico. Diventa però più vulnerabile se quel modello riduce drasticamente il costo cognitivo necessario per trasformare una vulnerabilità già nota in un exploit affidabile. È una distinzione fondamentale. L’AI non deve inventare una nuova classe di bug per modificare l’economia dell’attacco. Può essere sufficiente che renda industrializzabile ciò che prima richiedeva un ricercatore altamente specializzato.

Il problema economico è ancora più interessante. La cybersecurity ha sempre avuto un collo di bottiglia umano: trovare persone capaci di reverse engineering, exploit development, browser internals, kernel security e vulnerability research è costoso. Se un agente AI riesce a svolgere una parte crescente di quel lavoro, il valore marginale della competenza offensiva cambia. Il capitale non deve più comprare soltanto specialisti; può comprare compute, accesso ai modelli e tempo di esecuzione. La Silicon Valley, naturalmente, chiamerà questo processo “democratizzazione”. Il CISO potrebbe preferire chiamarlo con un nome meno rassicurante.

Il salto tra Mythos Preview e i modelli pubblici è quindi più importante del punteggio assoluto. ExploitBench sta fotografando una separazione tra capacità disponibili sul mercato e capacità mantenute ancora all’interno di programmi controllati. Anthropic stessa ha spiegato che la forza di Mythos Preview nella cybersecurity è stata una delle ragioni per cui il modello è stato distribuito inizialmente con forti restrizioni e all’interno di Project Glasswing.

Questa separazione, però, non è necessariamente stabile. A settembre 2026 Anthropic ha presentato Mythos 5.1 come evoluzione della famiglia Mythos, ancora disponibile soltanto a un gruppo ristretto di organizzazioni sottoposte a verifica. Nel frattempo altri modelli hanno iniziato ad avvicinarsi alla stessa frontiera: Anthropic ha riportato, per esempio, che GLM-5.3 ha completato exploit end-to-end su ExploitBench in 50 tentativi su 410, mentre Mythos Preview ha ottenuto 56 successi su 410 nella stessa valutazione.

Per la governance aziendale questo introduce un problema quasi banale nella sua formulazione e molto meno banale nella sua soluzione. Un controllo di sicurezza validato oggi non certifica necessariamente la resistenza del sistema contro il modello disponibile domani. Se la capacità offensiva cresce più rapidamente della frequenza con cui vengono rieseguiti i test, l’audit diventa una fotografia storica. Molto elegante, molto documentata, perfettamente inutile nel momento in cui cambia il soggetto dall’altra parte.

La conseguenza è che i benchmark di sicurezza dei modelli dovranno probabilmente diventare parte del processo di assurance, non un esercizio accademico parallelo. Non basta chiedere se un modello trova vulnerabilità. Bisogna misurare quanto lontano riesce a portare una vulnerabilità, quanto autonomamente costruisce una catena d’attacco, quali difese riesce ad attraversare e quanto costa farlo. La distinzione tra “ha trovato un bug” e “ha ottenuto execution” è la stessa distinzione che esiste tra avere una chiave e aprire la cassaforte.

Il punto più scomodo di ExploitBench è proprio questo: la distanza tra un modello relativamente innocuo e uno capace di compromettere seriamente un obiettivo non deve necessariamente essere colmata da dieci anni di ricerca. Può essere colmata da una generazione di modelli. Per un sistema di controllo basato su audit annuali, questa è una cattiva notizia. Per un’industria che continua a vendere assurance come se le capacità dell’attaccante fossero una costante, è una notizia ancora peggiore.

Paper: ExploitBench: A Capability Ladder Benchmark for LLM Cybersecurity Agents, arXiv. Il paper descrive i 16 livelli di capacità, gli oracle deterministici e la valutazione su 41 vulnerabilità V8. (arXiv)