Firefox è uno dei codebase più analizzati e testati al mondo, con oltre vent’anni di revisioni della community open source, collaudi automatizzati su scala industriale e programmi di bug bounty tra i più longevi del settore.
Eppure, in appena venti minuti dal primo avvio dell’analisi, Claude Opus 4.6 aveva già individuato la sua prima vulnerabilità critica: un bug di corruzione della memoria di tipo Use After Free nel motore JavaScript, una classe di bug di memoria che può consentire a un attaccante di sovrascrivere dati con contenuto malevolo arbitrario.
Questo è il dato che fa riflettere, al di là di tutto il resto.
Il Frontier Red Team di Anthropic ha pubblicato il 6 marzo 2026 un’analisi tecnica che ricostruisce nei dettagli la collaborazione con Mozilla. Il risultato finale: 22 CVE emesse, di cui 14 classificate ad alta severità da Mozilla stessa, quasi un quinto di tutte le vulnerabilità ad alta severità di Firefox corrette nell’intero 2025, scoperte in un solo mese. Tutte le vulnerabilità sono state corrette nella versione Firefox 148, già disponibile per gli utenti.
Il grafico pubblicato da Anthropic è eloquente: Claude Opus 4.6 ha fatto registrare nel solo mese di febbraio 2026 più vulnerabilità scoperte di quante ne fossero state segnalate in qualsiasi altro mese dell’anno precedente, da qualunque fonte.
Indice degli argomenti
Come ha lavorato Claude: metodologia e dettagli tecnici
La scelta di effettuare test su Firefox non è stata casuale: proprio perché è uno dei progetti open source più sicuri e rigorosi al mondo, ha rappresentato il banco di prova ideale per misurare le capacità reali del modello in condizioni estreme. Un altro contesto “facile” avrebbe detto poco.
Anche perché c’è un altro dettaglio operativo di particolare importanza: molti dei bug di bassa severità trovati erano assertion failure, una classe di problemi che il collaudo tradizionale del codice sorgente è in grado di intercettare facilmente. Ma il modello ha identificato anche classi di logic error che i cosiddetti fuzzer (gli strumenti automatizzati utilizzati per testare software) non avevano mai rilevato. Questo è il punto di discontinuità rispetto agli strumenti precedenti.
Il processo di analisi si è sviluppato in più fasi.
Fase 1: validazione su CVE storiche
Il team ha inizialmente chiesto a Claude di riprodurre vulnerabilità già note (CVE precedenti) su versioni più datate del codebase (che, lo ricordiamo, è l’insieme completo del codice sorgente utilizzato per sviluppare, compilare e far funzionare un’applicazione o un componente software specifico).
Il modello è riuscito a riprodurre un’alta percentuale di questi bug storici, ognuno dei quali aveva richiesto sforzo umano significativo per essere scoperto.
Un risultato già di per sé sorprendente, anche tenendo conto che parte del materiale poteva essere presente nei dati di addestramento.
Fase 2: ricerca di vulnerabilità inedite
Il vero test era trovare bug mai visti prima nel codice attuale di Firefox. L’analisi ha coperto quasi 6.000 file C++ dell’intero codebase, partendo dal motore JavaScript (SpiderMonkey) per poi estendersi ad altri componenti del browser.
Claude ha operato con un meccanismo di task verifier: uno strumento autonomo di verifica che gli consentiva di controllare in tempo reale la propria produzione, iterando e raffinando le ipotesi senza intervento umano continuo.
Questa capacità di self-check si è rivelata uno dei fattori chiave della qualità dei risultati.
Fase 3: segnalazione strutturata
Ogni report inviato a Mozilla tramite Bugzilla includeva test case minimi riproducibili, proof-of-concept dettagliati e patch candidate generate da Claude e validate dal team Anthropic.
Sono stati inviati in totale 112 report unici, includendo anche casi di crashing non immediatamente classificabili con una rilevanza di sicurezza su indicazione del team Mozilla stesso.
Il capitolo exploit: rassicurante, ma non del tutto
Anthropic ha anche testato la capacità del modello di non fermarsi alla scoperta, ma di sviluppare exploit funzionanti a partire dalle vulnerabilità identificate. Il risultato è stato parzialmente tranquillizzante, ma non privo di implicazioni.
Su centinaia di tentativi condotti con circa 4.000 dollari di crediti API, Claude è riuscito a trasformare la vulnerabilità in un exploit operativo solo in due casi e in condizioni di test deliberatamente semplificate, con alcune protezioni del browser disabilitate (in particolare la sandbox). Il modello è quindi molto più efficiente nel trovare i bug che nello sfruttarli.
Ci sono, però, due implicazioni da non sottovalutare.
La prima è che il costo di identificazione è un ordine di grandezza inferiore a quello di exploitation. Ciò significa che la barriera d’ingresso per chi cerca vulnerabilità si è abbassata drasticamente. Non necessariamente quella per chi le sfrutta, ma il gap tra scoperta e weaponizzazione potrebbe assottigliarsi rapidamente.
La seconda implicazione è data dal fatto che Claude ha comunque prodotto un exploit funzionante, seppur grezzo e in condizioni controllate e ciò indica che la direzione di sviluppo è quella.
Le difese “in depth” di Firefox (compresa la stessa sandbox del browser) hanno retto in questo caso, ma non si può fare affidamento su questo come unica linea di difesa in modo permanente.
Le implicazioni per la sicurezza: cosa cambia davvero
Questo caso non riguarda solo Firefox o Anthropic: ridisegna l’intero ecosistema del vulnerability research e ha conseguenze dirette per come le organizzazioni devono pensare alla propria postura di sicurezza.
Il vantaggio temporale è ora dei defender, ma devono muoversi
La buona notizia è strutturale: come dicevamo, Claude Opus 4.6 è molto più bravo a trovare vulnerabilità che a sfruttarle. Questo significa che, ad oggi, i defender che adottano sistemi di scansione delle vulnerabilità basati su sistemi assistiti dall’IA hanno un vantaggio reale rispetto agli attaccanti.
Ma è un vantaggio che si erode man mano che i modelli migliorano e che gli strumenti si democratizzano.
Dunque, le organizzazioni con codebase critici (software house, produttori di sistemi embedded, sviluppatori di applicazioni Enterprise) devono iniziare già adesso a integrare strumenti assistiti dall’IA per l’analisi statica dei malware e la detection delle vulnerabilità durante tutto il ciclo di sviluppo.
Tenendo conto che lo stesso approccio usato da Anthropic con Firefox è replicabile con strumenti già disponibili sul mercato.
Il collaudo automatizzato del codice da solo non basta più
Per anni il cosiddetto fuzzing è stato lo standard per eccellenza nella ricerca automatizzata di vulnerabilità. Firefox stesso ha investito enormemente in questa tecnica.
Eppure, come abbiamo visto, Claude ha trovato classi di bug che il fuzzing non aveva mai intercettato: pensiamo, in particolare, a tutti quegli errori logici che non producono crash immediati delle applicazioni ma creano condizioni di memoria corrotta sfruttabili in seguito.
Questo vuol dire che, nei programmi di Application Security Testing, il fuzzing non va eliminato, ma deve essere affiancato da analisi semantica assistita dall’intelligenza artificiale. La tradizionale analisi statica del codice (SAST, Static Application Security Testing) non è sufficiente. I team di sicurezza devono rivedere la propria “cassetta degli attrezzi” includendo strumenti che ragionano sul codice piuttosto che limitarsi a cercarne pattern.
I programmi di Vulnerability Disclosure devono aggiornarsi
Il caso Mozilla/Anthropic ha definito de facto un nuovo standard per la disclosure responsabile di vulnerabilità individuate con l’intelligenza artificiale. I report includevano: test case minimi riproducibili, proof-of-concept verificati, patch candidate.
Questa qualità di segnalazione, impensabile se riportata in un contesto esclusivamente basato sul solo lavoro umano, diventerà la norma attesa.
Alla luce di ciò, le organizzazioni che gestiscono un programma di bug bounty o un processo di Coordinated Vulnerability Disclosure devono aggiornarsi: i report generati con l’intelligenza artificiale saranno sempre più frequenti, sempre più dettagliati e in volume crescente.
Di conseguenza, i processi di selezione e classificazione devono essere in grado di gestirli senza collassare. La buona notizia è che Anthropic ha pubblicato anche i propri principi operativi di Coordinated Vulnerability Disclosure che le aziende possono quindi leggere e usare come benchmark di riferimento.
La superficie di attacco sul codice legacy si è ampliata
La ricerca condotta dagli analisti di Anthropic ha evidenziato anche un altro aspetto importante su cui è utile soffermarsi e ragionare: se un modello IA riesce a trovare 22 vulnerabilità in uno dei codebase più presidiati al mondo come quello di Firefox, cosa succede in contesti in cui i controlli di sicurezza meno rigorosi?
Software legacy, applicazioni Enterprise scritte negli anni ‘90 e sistemi embedded mai sottoposti a revisione sistematica rappresentano una superficie di attacco enorme che strumenti come Claude possono analizzare in tempi impensabili per un team umano.
Quanto dimostrato da Anthropic conferma l’indispensabilità di attivare una valutazione urgente del rischio sul codice legacy in produzione, in particolare per applicazioni che gestiscono dati sensibili o si trovano nel perimetro di infrastrutture critiche.
Non è più realistico assumere che “non è stato trovato niente finora” equivalga a “non c’è niente da trovare”. Questo perché gli strumenti che non c’erano prima adesso, nel bene e nel male, ci sono.
Aggiornare Firefox (e tutti i browser) è non negoziabile
È questo il messaggio più semplice, ma anche il più diretto che possiamo trarre dalla ricerca pubblicata da Anthropic. Se è vero che i 14 bug ad alta severità identificati da Claude sono stati corretti in Firefox 148, è altrettanto vero che chi non ha ancora aggiornato i propri sistemi risulta essere esposto a vulnerabilità ora pubblicamente note, su cui si può costruire un exploit.
Il tempo tra disclosure e weaponizzazione si sta accorciando, per cui è importante verificare immediatamente la versione di Firefox installata su tutti i dispositivi aziendali e personali, oltre che abilitare gli aggiornamenti automatici ove possibile.
Nei contesti aziendali, invece, diventa requisito imprescindibile l’aggiornamento del processo di patch management al fine di garantire che gli aggiornamenti dei browser vengano distribuiti entro 24-48 ore dalla release, non settimane dopo.
Risk management: leggere il segnale oltre il caso specifico
Dal punto di vista della gestione del rischio, questo caso introduce una discontinuità che merita attenzione strategica, non solo operativa.
L’intelligenza artificiale applicata alla ricerca di vulnerabilità nelle applicazioni non è più una promessa da laboratorio ma uno strumento operativo che ha trovato, in produzione, bug critici in uno dei software più testati al mondo. Il cambio di paradigma è triplice:
- Velocità: ciò che richiedeva mesi di lavoro umano specializzato ora richiede ore o giorni. Il ciclo find-fix deve accelerare di pari passo.
- Costo: il costo per unità di vulnerabilità scoperta è crollato. Questo abbassa la barriera d’ingresso per chi intende usare questi strumenti in modo offensivo.
- Scala: un singolo modello può analizzare migliaia di file in parallelo, coprire classi di bug che i tool tradizionali non vedono, e farlo su qualunque codebase accessibile.
Il messaggio per i responsabili della sicurezza aziendale è chiaro: il modello di rischio residuo adottato soltanto sei mesi fa non è più valido, deve essere aggiornato tenendo conto che la velocità di scoperta delle vulnerabilità è aumentata di un ordine di grandezza.
Di conseguenza, i piani di patch management, i cicli di release del software e i processi di classificazione delle vulnerabilità devono essere calibrati su questi nuovi ritmi.
È il momento del defender advantage: non sprechiamolo
Come accennavamo all’inizio, c’è una finestra temporale, probabilmente non lunghissima, in cui chi deve difendersi ha un vantaggio strutturale: i modelli IA sono molto più bravi a trovare vulnerabilità che a sfruttarle.
Mozilla e Anthropic hanno dimostrato come si usa questa finestra grazie a stretta collaborazione, disclosure responsabile, patch rapide e integrazione degli strumenti di intelligenza artificiale nei workflow di sicurezza interni.
Il settore dello sviluppo software ha la stessa opportunità e va da sé che il momento giusto per adottarla non è quando il vantaggio si è già chiuso.
