In questo articolo Indice dei contenuti 2 sezioni
Sono bastati sei giorni ai ricercatori di XBOW per violare Google Chrome con l’aiuto dell’intelligenza artificiale, concatenando tre vulnerabilità del browser fino ad aprire un programma su Windows. Il team ha sfruttato agenti AI per costruire una catena di exploit in grado di trasformare una comune pagina web in una porta d’accesso al sistema operativo. La dimostrazione si chiude con l’avvio della Calcolatrice di Windows, il classico segnale usato da sempre per provare una falla di questo genere.
Il lavoro è stato pubblicato il 13 ottobre 2026 e ha portato al gruppo una ricompensa di EUR 223.314, circa 215.000 euro, nell’ambito del Chrome Vulnerability Reward Program di Google. Si tratta del primo premio di questa entità assegnato per una catena completa di compromissione secondo le regole introdotte nell’aprile 2026. Colpiscono anche i tempi. Lo sviluppo è avvenuto dal 2 al 7 agosto 2026 con una spesa di circa EUR 35.730, all’incirca 35.000 euro, in chiamate API ai modelli. Va detto subito che Google ha già sistemato tutto con aggiornamenti distribuiti tra agosto e settembre 2026. Chi usa Chrome 153 o versioni successive è al sicuro da qualsiasi tentativo di sfruttare queste falle.
Come gli agenti AI hanno lavorato su Chrome
Il dettaglio più interessante riguarda il ruolo dell’intelligenza artificiale nella ricerca. XBOW ha impiegato agenti basati sul modello GPT 5.6 sol di OpenAI e ha affidato a ciascuno compiti diversi: analizzare il codice sorgente, scovare possibili difetti, verificare ipotesi e scrivere le singole parti dell’attacco. Gli agenti si concentravano su problemi ben delimitati, mentre gli esperti umani sceglievano gli obiettivi, leggevano i risultati e decidevano come mettere insieme le tecniche trovate. C’era chi si occupava del motore JavaScript, chi dei meccanismi di isolamento della memoria e chi della possibilità di uscire dal processo che esegue le pagine web.
Secondo XBOW, prima dei modelli linguistici avanzati un exploit di questa complessità avrebbe richiesto a quattro specialisti dai 6 ai 9 mesi. La vera svolta sta nella possibilità di esplorare molte strade in parallelo, provando soluzioni alternative e scartando in fretta quelle che non funzionano. Una accelerazione che può servire tanto a trovare e correggere i bug quanto a progettare attacchi.
Tre falle diverse con un difetto in comune
Il primo anello della catena era Maglev, il compilatore del motore V8 che ottimizza il codice JavaScript. Un errore nella gestione di alcuni oggetti numerici consentiva di aggirare i controlli sui limiti degli array e di leggere o modificare la memoria interna alla sandbox di V8. Per uscire da quell’area protetta i ricercatori hanno usato un secondo difetto nel decoder delle immagini WebP animate. Manipolando un buffer tramite le API WebCodecs hanno spinto Chrome a usare le dimensioni di un’immagine per decodificare i pixel di un’altra, provocando un heap buffer overflow. Da lì è stato possibile scrivere nella memoria nativa, alterare i riferimenti al codice WebAssembly ed eseguire istruzioni nel processo renderer, ancora però confinato dalla sandbox del browser.
L’ultimo passo ha coinvolto Crashpad, il componente che raccoglie dati sugli arresti anomali. Sfruttando il flag di Windows THREADCREATEFLAGSBYPASSPROCESS_FREEZE il team ha tenuto attivo un thread mentre Crashpad considerava sospeso il processo. Cambiando i permessi delle pagine di memoria durante le letture, l’exploit ha generato una seconda scrittura oltre i limiti del buffer, stavolta nel processo Crashpad che si trova fuori dalla sandbox. Agendo sulle strutture interne e sfruttando funzioni già presenti in Chrome, i ricercatori hanno richiamato l’API CreateProcessW() aprendo la Calcolatrice di Windows. Al suo posto avrebbero potuto lanciare altri comandi in locale.
Guardando i tre problemi insieme salta fuori un tratto comune piuttosto curioso. Il compilatore riteneva immutabile un oggetto numerico che invece poteva cambiare. Il decoder WebP dava per scontato che i dati arrivati da JavaScript restassero fermi. Crashpad era convinto che un processo sospeso non potesse toccare le proprie pagine di memoria. Tre componenti lontanissimi tra loro, accomunati dalla stessa debolezza: fidarsi di una condizione senza garantire che resti valida. Le falle non nascono per forza da un controllo mancante o da un’istruzione palesemente rischiosa ma anche da supposizioni in apparenza sensate, che crollano quando parti diverse interagiscono in situazioni impreviste.
La scoperta conferma il peso delle protezioni multiple di Chrome, visto che per comprometterlo non è servito un singolo bug ma una sequenza molto elaborata di errori trasformata in un attacco funzionante. A fare notizia è la rapidità con cui gli agenti AI hanno permesso di passare da una pagina JavaScript all’apertura della Calcolatrice di Windows in appena 6 giorni.
Fonte: TecnoAndroid