Chrome: catena da 250.000 dollari scritta con l’IA in sei giorni

Un gruppo di ricercatori di XBOW, società statunitense che si occupa di penetration test con l’intelligenza artificiale, ha costruito una catena di exploit completa (full-chain) contro Google Chrome su Windows: da una pagina web malevola fino all’esecuzione di codice sul computer, fuori da tutte le sandbox del browser. Lo hanno fatto in sei giorni, con circa 40.000 dollari di costi di calcolo e con GPT-5.6 Sol, un modello di OpenAI disponibile al pubblico. Google ha corretto le tre vulnerabilità e ha pagato 250.000 dollari di ricompensa.

All’inizio di ottobre ARX News aveva raccontato lo stop dell’OSS VRP di Google, sommerso da segnalazioni automatiche non valide. Questo caso mostra l’altra faccia dello stesso fenomeno: l’IA, guidata da persone esperte, produce anche risultati di altissimo livello.

Cosa è successo

I fatti principali sono concordi tra le fonti: tre zero-day in Chrome, un modello pubblico di OpenAI, sei giorni di lavoro, 40.000 dollari di costi, 250.000 dollari di ricompensa. Secondo The Register, il lavoro si è svolto durante le conferenze Black Hat e DEF CON e la ricompensa è la più alta prevista da Google per una full-chain di Chrome; CSO Online aggiunge che è la prima pagata con le regole del 2026 del programma. XBOW stima che la catena potesse colpire circa un miliardo di utenti Windows.

Secondo CSO Online, i ricercatori hanno scelto un modello generalista, e non uno strumento specializzato, proprio per mostrare cosa si può ottenere con un modello pubblico. The Register riporta la divisione dei compiti descritta da Brendan Dolan-Gavitt, uno dei quattro ricercatori, nel resoconto tecnico di XBOW:

• gli agenti di IA hanno cercato nel codice sorgente di Chrome, verificato le ipotesi del gruppo e sviluppato le prove di concetto e le singole fasi dell’exploit;
• le persone hanno scelto dove cercare, fornito il contesto, contestato i risultati degli agenti e deciso quali componenti concatenare. «Abbiamo applicato una buona dose della nostra esperienza e del nostro giudizio», ha scritto Dolan-Gavitt.

La catena di attacco

Chrome isola il codice in due livelli: la sandbox di V8 contiene gli effetti dei bug di memoria del motore JavaScript dentro il processo renderer, e la sandbox del sistema operativo limita a sua volta il renderer. Uscire dalla prima non dà automaticamente l’esecuzione di codice nativo; uscire dalla seconda significa arrivare al sistema. Secondo il resoconto riportato da The Register, la catena supera entrambe le barriere in tre passi:

1. Maglev, il compilatore ottimizzante di livello intermedio di V8: un numero «boxed» mutabile riusato durante la deottimizzazione dà lettura e scrittura in tutta la gabbia di compressione dei puntatori di V8;
2. decodifica delle immagini WebP animate: un bug usato per uscire dalla sandbox di V8, non attaccando la sandbox in sé ma una proprietà che la sandbox volutamente non garantisce e che Blink, il motore di rendering, considerava invece affidabile;
3. Crashpad, il componente che raccoglie i dati dei crash: un overflow usato per superare la sandbox del processo ed eseguire codice sul sistema senza restrizioni.

CSO Online descrive il risultato finale come l’avvio di un’applicazione Windows a partire da una pagina web malevola. Le fonti non indicano i numeri CVE delle tre vulnerabilità e non parlano di sfruttamento reale: si tratta di una ricerca segnalata a Google.

In termini MITRE ATT&CK, una catena del genere usata in un attacco corrisponderebbe a una compromissione durante la navigazione (T1189, Drive-by Compromise) seguita dall’esecuzione di codice sul client sfruttando il browser (T1203).

Cosa cambia per chi difende

Il punto non è questa catena, già corretta, ma i tempi e i costi. L’amministratore delegato di XBOW, Oege de Moor, riferisce che secondo un ex membro di un’agenzia di intelligence un lavoro simile richiedeva sei mesi; qui ne sono bastati sei giorni. Dolan-Gavitt conclude che per chi attacca con i modelli linguistici «l’asticella è molto più bassa» e invita a difendersi di conseguenza.

Per le aziende europee e italiane questo significa una finestra più stretta tra la pubblicazione di una correzione e la comparsa di exploit funzionanti. Il browser è il software più esposto di ogni postazione, anche nelle strutture sanitarie e negli ambienti condivisi. Per i soggetti NIS2 la gestione degli aggiornamenti fa parte delle misure di gestione del rischio: se i tempi di patch dei browser si misurano in settimane, vanno rivisti.

Cosa fare subito

1. Verifica la versione di Chrome: secondo The Register serve la 152.0.7977.82 o successiva. Controlla l’inventario di tutte le postazioni Windows, non solo quelle gestite centralmente.
2. Imponi il riavvio del browser: Chrome si aggiorna da solo, ma la correzione si applica solo quando il browser viene riaperto. Usa le policy di gestione per chiedere e poi forzare il riavvio entro un tempo stabilito.
3. Controlla gli altri browser basati su Chromium: le fonti non dicono se e quando gli altri produttori abbiano integrato le correzioni. Segui i loro avvisi.
4. Non disattivare la sandbox (per esempio con --no-sandbox in chioschi, automazioni o applicazioni incorporate): è proprio la barriera che costringe chi attacca a costruire una catena.
5. Sorveglia i processi avviati dal browser: un’applicazione lanciata da un processo di Chrome in modo insolito è un segnale da indagare con la soluzione antivirus/EDR.
6. Accorcia i tempi di patch dei browser e trattali come quelli del sistema operativo: con l’IA, il tempo tra correzione ed exploit può ridursi.

Come aiuta ARXDOME

ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, con la loro età e quelle già sfruttate in evidenza: aiuta a trovare le postazioni con un browser rimasto indietro. ARX Sentry raccoglie l’inventario di software e processi di computer e server e segnala le esecuzioni sospette, utili per riconoscere processi anomali avviati dal browser.

Ultimo aggiornamento: 16 ottobre 2026