Come l'AI trova vulnerabilità zero-day: il metodo tecnico di Claude Mythos Preview

84% su Firefox 147: il numero che cambia la conversazione

Su un benchmark di exploitation reale di Firefox 147, Claude Mythos Preview raggiunge l'84.0% di successo. Claude Opus 4.6, il modello precedente di punta, si ferma al 15.2%.

Non è un miglioramento incrementale. È un salto qualitativo che sposta Mythos in una categoria diversa.

Su CyberGym Vulnerability Reproduction — un set di vulnerabilità reali da riprodurre in ambiente controllato — Mythos arriva all'83.1% contro il 66.6% di Opus 4.6. Il divario è netto, ma più contenuto. Il Firefox benchmark è quello che più sorprende: quasi sei volte il tasso di successo del predecessore, su exploitation end-to-end di un browser moderno con tutte le protezioni attive.

Per capire cosa significa, bisogna guardare il metodo. Non la performance, il metodo.

Le categorie di vulnerabilità che Mythos identifica

Il profilo documentato da Anthropic copre categorie diverse, alcune delle quali sono tra le più complesse nel panorama della sicurezza offensiva.

Buffer overflow con signed integer overflow. Un esempio concreto: il bug di 27 anni in OpenBSD, dove un null-pointer dereference nasce da un overflow in un confronto di sequence number. Non un errore ovvio, ma il tipo di bug che sopravvive a decenni di review perché emerge solo in condizioni specifiche.

Use-after-free e out-of-bounds read/write. Accessi a memoria dopo la deallocazione, letture e scritture fuori dai limiti — la fonte di gran parte delle vulnerabilità critiche nei browser moderni.

Heap corruption con cross-cache reclamation. Tecniche che sfruttano il comportamento dell'allocatore di memoria per sovrascrivere strutture dati critiche.

Attacchi multi-vulnerabilità combinati: JIT heap spray che combina quattro vulnerabilità distinte, browser sandbox escape con renderer-to-OS privilege escalation, ROP chain distribuita su più pacchetti di rete. Tutto su sistemi hardened con ASLR, stack protection e W^X attivi.

Per le vulnerabilità logiche: authentication bypass, CSRF, injection, debolezze in TLS/AES-GCM/SSH. Per il kernel: bypass di KASLR via kernel pointer disclosure deliberata a userspace.

Un caso specifico per la sua nitidezza tecnica: il bug FFmpeg H.264, dove una collisione del sentinello del numero di slice causa heap out-of-bounds write per mismatch tra gestione a 16 bit e 32 bit del contatore.

Come funziona il processo: dall'analisi all'exploit funzionante

Il metodo ha una struttura riconoscibile. Capirla è utile non solo per valutare le capacità di Mythos, ma per capire come un team tecnico può usare approcci simili con i modelli disponibili oggi.

La prima fase è l'analisi del codice sorgente con generazione di ipotesi. Il modello non scansiona meccanicamente cercando pattern noti. Costruisce un modello mentale del sistema — come interagiscono i componenti, dove passano i dati, quali assunzioni implicite potrebbero essere violate — e genera ipotesi su dove potrebbero nascondersi i problemi.

La seconda fase è il testing dinamico con debugger. Le ipotesi vengono verificate in ambiente containerizzato, con analisi del comportamento a runtime.

La terza fase, quella che distingue Mythos dal modello precedente, è il triage. Sonnet 4.6 migliora se vengono rimossi i bug principali dal contesto — non ha un meccanismo efficace per filtrare autonomamente le piste più promettenti. Mythos identifica immediatamente i vettori più efficaci, filtra automaticamente i finding a bassa criticità, converge sulle vulnerabilità che vale la pena sviluppare.

A scala industriale: circa 1.000 scan su OpenBSD a un costo di 20.000 dollari, con decine di finding reali come risultato.

Il reverse engineering da binari: una capacità nuova e importante

Tra le capacità documentate, una merita attenzione particolare per le implicazioni pratiche.

Mythos riesce a ricostruire codice sorgente plausibile a partire da stripped binaries — eseguibili da cui sono state rimosse le informazioni di debug. Partendo dal codice macchina, ricostruisce la logica del programma, le strutture dati, le assunzioni implicite del programmatore. Poi cerca vulnerabilità in questa ricostruzione.

Il significato pratico: è possibile fare security research su firmware closed-source, su librerie distribuite solo in forma compilata, su componenti di terze parti di cui non si ha il sorgente.

Questo cambia il perimetro della code review. Non si è più limitati al codice che si possiede. Qualsiasi binario che entra nel sistema — una dipendenza, un componente hardware, un plugin — diventa analizzabile.

Per i team che lavorano su supply chain security o analisi di componenti legacy, questa capacità apre uno scenario che fino a poco tempo fa richiedeva esperti specializzati e tempi molto più lunghi.

Cosa cambia per code review e secure development nei team

Mythos non è disponibile in produzione. Ma le capacità che dimostra indicano una direzione che i team tecnici possono iniziare a percorrere con i modelli disponibili oggi.

Pre-commit e pull request review: integrare un'analisi di sicurezza sistematica nel workflow di sviluppo, non come revisione manuale occasionale ma come processo automatico su ogni modifica.

Vulnerability triage: quando si lavora su codebase legacy o si analizzano dipendenze, la capacità di prioritizzare i finding per impatto reale — piuttosto che per severità nominale — riduce il tempo sprecato su problemi teorici a bassa probabilità di sfruttamento.

Formazione contestuale: capire come funziona un exploit su codice simile a quello che si scrive ogni giorno cambia come si scrive codice sicuro. Non è teoria astratta, è pattern recognition applicata al proprio contesto.

Il prompt engineering per la sicurezza del codice è un'area dove l'investimento in know-how produce risultati misurabili in tempi brevi.

Come formare il tuo team su Claude per la sicurezza del codice

Il divario tra cosa i modelli AI possono fare per la sicurezza del codice e cosa i team tecnici usano realmente è ancora ampio. Non per mancanza di capacità dei modelli, ma per mancanza di metodo e pratica.

Usare Claude per code review richiede di sapere come strutturare le richieste, come fornire contesto, come interpretare i risultati e dove il modello tende a sbagliare. Non è complicato, ma richiede pratica su casi reali.

I workshop di Maverick AI per team tecnici partono da qui: non dalla teoria sui modelli, ma dall'applicazione diretta al codice del team. Si lavora su Claude Code per l'analisi del sorgente, si costruisce un workflow di code review AI-assistita adatto al contesto specifico, si pratica su vulnerabilità di tipologie analoghe a quelle presenti nel codebase.

L'obiettivo non è che il team sappia cosa può fare Mythos. È che usi Claude ogni giorno per scrivere codice più sicuro, trovare problemi prima che arrivino in produzione, e ridurre il tempo dedicato a code review manuale su pattern che un modello riconosce in secondi.

Se vuoi capire come strutturare un percorso del genere per il tuo team, parliamone.