L'exploit XBOW GPT-5.6 per Chrome ha ottenuto la ricompensa full-chain di Google da 250.000 dollari
XBOW ha costruito in sei giorni una catena di exploit per Chrome composta da tre bug, ottenendo la ricompensa massima full-chain di Google da 250.000 dollari. L'exploit XBOW GPT-5.6 per Chrome partiva da normale JavaScript e si concludeva con codice in esecuzione al di fuori di ogni sandbox di Chrome su Windows.
Questo risultato non significa che un modello di AI abbia sconfitto Chrome in autonomia. Il ricercatore Brendan Dolan-Gavitt ha scelto gli obiettivi, fornito il contesto, esaminato le scoperte e collegato le fasi dell'exploit. Agenti che utilizzavano il modello gpt-5.6-sol di OpenAI, disponibile pubblicamente, hanno cercato nel codice sorgente, testato ipotesi e redatto proof of concept.
La storia più significativa riguarda la compressione dei tempi di ricerca. XBOW afferma che un lavoro paragonabile richiedeva in passato quattro specialisti e da sei a nove mesi. La sua catena premiata è emersa durante uno sprint di agosto, dopo che ricerche precedenti, tecniche riutilizzabili e una catena fallita avevano preparato il terreno.
Google ha riprodotto l'exploit finale, corretto le sue tre vulnerabilità e approvato la ricompensa. Questi fatti spostano il progetto oltre il perimetro di un benchmark privato. Espongono inoltre la vera pressione competitiva: i difensori dei browser devono ora confrontarsi con una ricerca di vulnerabilità su scala macchina, guidata da esseri umani esperti.
La catena di sei giorni ha attraversato ogni sandbox di Chrome
Il cambiamento decisivo non è stato trovare un singolo bug di Chrome, ma collegare tre falle indipendenti in un percorso verificato da una pagina web all'esecuzione di codice su Windows.
XBOW ha costruito la catena premiata dal 2 al 7 agosto 2026, mentre i ricercatori partecipavano a Black Hat e DEF CON a Las Vegas. L'azienda ha reso pubblico il lavoro il 13 ottobre, dopo che Google aveva distribuito le correzioni.
Una catena completa combina vulnerabilità che forniscono capacità differenti. Ogni fase porta l'attaccante oltre un confine di sicurezza separato che una sola falla non può superare da sola.
La prima fase prendeva di mira V8, il motore JavaScript di Chrome. Un errore del compilatore consentiva all'exploit di ottenere un ampio accesso in lettura e scrittura all'interno della regione di memoria protetta di V8.
V8 colloca la maggior parte degli oggetti JavaScript in uno spazio di indirizzi isolato di quattro gibibyte. Questa sandbox in-process limita ciò che un attaccante può raggiungere dopo aver corrotto un oggetto JavaScript.
La seconda fase attaccava il percorso di decodifica WebP animata di Chrome. Convertiva l'accesso a V8 in una scrittura precisa al di fuori di quella regione protetta, attraversando il primo grande confine.
La terza fase prendeva di mira Crashpad, il componente di Chrome per la segnalazione degli arresti anomali. Crashpad opera al di fuori della sandbox del renderer perché deve ispezionare i processi quando falliscono.
Quella vulnerabilità finale trasformava la limitata capacità di scrittura in memoria nell'esecuzione di codice all'interno del gestore degli arresti anomali non sottoposto a sandbox. XBOW ha dimostrato il risultato avviando l'applicazione Calcolatrice di Windows da una normale pagina Chrome Beta.
L'analisi dettagliata dell'exploit di Dolan-Gavitt documenta le tre fasi e le loro interfacce. Descrive inoltre i ruoli umani e delle macchine alla base del lavoro.
L'attacco non richiedeva un download né un clic aggiuntivo dopo il caricamento della pagina. Prima della correzione, un sito malevolo avrebbe potuto teoricamente attivare la catena attraverso il solo contenuto del browser.
XBOW afferma che le vulnerabilità non sono mai state utilizzate contro gli utenti di Chrome. Le ha inviate tramite il Vulnerability Reward Program di Google, dando a Google il tempo di riprodurre e correggere le falle prima della pubblicazione.
Il tracker pubblico delle issue di Google conferma in modo indipendente l'esito più importante. Un ingegnere ha registrato che l'exploit avviava Calcolatrice da Chrome Beta, e il programma ha approvato una ricompensa di 250.000 dollari.
Questa verifica è importante perché le dimostrazioni aziendali possono omettere vincoli ambientali. In questo caso, il record di Google conferma che la catena funzionava e si qualificava per il suo bonus più elevato per exploit dei browser.
La ricompensa è stata inoltre il primo pagamento full-chain previsto dalle regole introdotte da Google nell'aprile 2026. Tali regole riservano l'importo massimo a un exploit che inizia con contenuti web e compromette il processo del browser.
Google limita il programma a quattro bonus di questo tipo nel corso del 2026. Le sue regole del Chrome VRP trattano quindi le catene funzionanti come segnalazioni rare e di valore eccezionale.
La catena finale non è stata il primo tentativo di XBOW. Un percorso precedente si basava su una vulnerabilità che Google già conosceva, rendendo quel componente un duplicato e non idoneo a una nuova ricompensa.
XBOW ha evitato di perdere l'intero progetto perché aveva separato l'exploit in moduli intercambiabili. Dolan-Gavitt e gli agenti hanno sostituito la fase centrale duplicata con la falla della WebP animata.
Questa sostituzione è centrale nella storia. Il risultato dipendeva da un sistema di ricerca riutilizzabile, non da un singolo prompt ispirato che ha prodotto un exploit dal nulla.
Perché l'exploit XBOW GPT-5.6 per Chrome cambia la curva dei costi
Il risultato ottenuto in sei giorni mette sotto pressione i fornitori di browser perché comprime il costoso lavoro di ricerca, test e integrazione necessario per lo sfruttamento avanzato.
Una catena completa per Chrome ha tradizionalmente richiesto competenze rare in compilatori, componenti interni dei browser, sistemi operativi e mitigazioni degli exploit. I ricercatori devono trovare falle che siano al tempo stesso nuove e compatibili.
Devono poi trasformare bug isolati in capacità stabili. Una fase potrebbe esporre la memoria, un'altra attraversare una sandbox e una terza completare l'esecuzione di codice.
XBOW afferma che prima dei large language model un team di quattro persone impiegava circa sei-nove mesi per un lavoro simile. La sua prima catena completa interna ha richiesto circa due mesi.
La catena premiata ha richiesto sei giorni. XBOW ha ricostruito il proprio utilizzo dai log archiviati degli agenti e ha stimato circa 40.000 dollari di addebiti API per lo sprint.
Questo confronto necessita di un'attenta contestualizzazione. La campagna di sei giorni non è partita da zero in termini di conoscenza organizzativa. È arrivata dopo mesi di esplorazione e una precedente catena completa.
I ricercatori di XBOW hanno inoltre fornito tecniche di sfruttamento sviluppate in progetti precedenti. Gli agenti potevano attingere a esempi di alta qualità, strumenti consolidati e un'architettura modulare.
Anche con queste precisazioni, il cambiamento resta sostanziale. Le competenze riutilizzabili possono ora essere replicate in sessioni parallele di agenti, anziché restare limitate all'attenzione di un singolo ricercatore.
Gli agenti hanno eseguito ampie ricerche nel codice sorgente, generato ipotesi, scritto programmi di test e perfezionato le prime fasi dell'exploit. Gli esseri umani si sono concentrati su strategia, validazione e decisioni che collegavano il lavoro.
Questa divisione cambia l'economia della ricerca sulle vulnerabilità. La revisione del codice sorgente e l'iterazione sperimentale possono assorbire enormi quantità di tempo degli esperti, anche quando la maggior parte dei tentativi fallisce.
Gli agenti possono condurre contemporaneamente diverse campagne più ristrette. XBOW ha suddiviso il problema in scoperta delle vulnerabilità, corruzione di V8, evasione della sandbox, evasione del renderer e integrazione finale.
Il parallelismo non garantisce il successo. Aumenta il numero di percorsi tecnicamente plausibili che un essere umano può esaminare entro un periodo prefissato.
La ricompensa di 250.000 dollari ha superato di 210.000 dollari la spesa API riportata, prima di stipendi, infrastruttura e costi delle ricerche precedenti. Questa aritmetica non dimostra un margine di profitto ripetibile.
Le ricompense dei bug bounty dipendono da novità, gravità, riproducibilità e tempistica. Una vulnerabilità tecnicamente valida può diventare priva di valore per chi la segnala se un'altra parte l'ha inviata per prima.
La vulnerabilità Gin duplicata ha mostrato questo rischio durante il progetto. Un numero maggiore di ricercatori automatizzati che cercano nello stesso codice open source probabilmente aumenterà tali collisioni.
Google sta inoltre utilizzando tecniche assistite dall'AI nel proprio lavoro di sicurezza. La competizione non è quindi semplicemente tra attaccanti AI e difensori umani.
È una corsa tra organizzazioni capaci di trasformare i modelli in sistemi di ricerca affidabili. Selezione degli obiettivi, gestione delle prove, riproduzione e disciplina nella divulgazione diventano fattori differenzianti.
Per i team che sviluppano browser, una ricerca esterna più veloce crea pressione operativa. I fornitori devono riprodurre le segnalazioni, preparare correzioni, coordinare le release e valutare il codice correlato prima che si diffondano i dettagli tecnici.
La pressione si estende oltre Google. Qualsiasi azienda che distribuisce una grande applicazione in codice nativo affronta ora una barriera più bassa per individuare interazioni tra molteplici sottosistemi.
Software desktop, server e dispositivi embedded contengono gli stessi tipi di assunzioni nascoste. Un componente si fida di un valore che un altro componente può modificare in modo imprevisto.
Il risultato di XBOW suggerisce che queste assunzioni tra componenti siano bersagli particolarmente produttivi per la ricerca assistita dall'AI. I modelli possono cercare ampiamente nel codice sorgente e collegare dettagli di implementazione poco evidenti.
Questa capacità favorisce i difensori che possono testare continuamente i propri sistemi. Favorisce anche gli attaccanti che possono permettersi campagne ripetute senza divulgare scoperte non riuscite o pericolose.
Tre assunzioni mutabili hanno reso possibile l'exploit
Ogni fase ha infranto una diversa assunzione che Chrome trattava come stabile, offrendo agli agenti un modello tecnico coerente da perseguire.
La prima vulnerabilità è emersa in Maglev, il compilatore ottimizzante di fascia intermedia di V8. Maglev accelera JavaScript formulando assunzioni sulle forme e sui valori degli oggetti.
Quando un'assunzione non è valida, V8 esegue una deottimizzazione. Ricostruisce normali oggetti JavaScript e riprende l'esecuzione in codice meno specializzato.
Il percorso vulnerabile riutilizzava un numero incapsulato che avrebbe dovuto essere ricreato separatamente. Due oggetti ricostruiti potevano quindi condividere un valore mutabile, mentre la logica del compilatore lo trattava come immutabile.
L'exploit modificava quel valore condiviso tra due osservazioni. Un controllo approvava un indice di array sicuro, mentre un'operazione successiva utilizzava il valore alterato come offset effettivo.
Questa discrepanza ha prodotto accesso alla memoria attraverso la regione isolata di V8. Da JavaScript, l'exploit poteva ispezionare puntatori e manipolare oggetti all'interno della sandbox.
La correzione di Google ha eliminato il riutilizzo non sicuro. V8 ora materializza un nuovo numero incapsulato per ogni oggetto pertinente, invece di deduplicare il valore ritenuto costante.
La seconda vulnerabilità sfruttava un'altra assunzione sulla proprietà. L'interfaccia WebCodecs di Chrome consente a JavaScript di trasferire un ArrayBuffer a un decoder di immagini.
Secondo la normale semantica di JavaScript, il trasferimento di quel buffer scollega le vecchie viste. Il decoder può quindi trattare i byte sottostanti come posseduti in esclusiva e stabili.
Un attaccante che controlla già la sandbox di V8 può corrompere la contabilità che impone lo scollegamento. XBOW ha mantenuto attiva una vista dopo che Chrome aveva ritenuto completo il trasferimento.
L'exploit ha collocato due immagini WebP animate valide di uguale lunghezza nella stessa memoria. Ha lasciato che Chrome ispezionasse la geometria di un'immagine, quindi ne ha sostituito i byte con quelli dell'altra.
Il decoder ha combinato dimensioni memorizzate nella cache dalla prima immagine con dati pixel della seconda. Questa falla time-of-check to time-of-use ha causato un overflow dell'heap nativo.
XBOW ha perfezionato l'overflow fino a ottenere una scrittura selezionata a 64 bit a un indirizzo nativo selezionato. È stato sufficiente per preparare il codice all'interno del renderer all'ultimo attraversamento di confine.
La terza vulnerabilità riguardava la convinzione di Crashpad che un renderer sospeso non potesse cambiare. Crashpad mette in pausa un processo prima di leggerne la memoria per un report di arresto anomalo.
Windows supporta uno speciale flag dei thread che può aggirare il congelamento di un processo. XBOW ha creato un thread di questo tipo e ha modificato i permessi della pagina mentre Crashpad eseguiva due letture correlate.
La prima lettura di Crashpad non è riuscita. La sua logica di recupero ha dedotto che i dati richiesti avessero attraversato un confine di pagina, quindi ha riprovato con una lunghezza maggiore.
Il thread esente dal freeze ha reso leggibile la pagina sorgente prima del nuovo tentativo. Crashpad ha copiato più dati di quanti ne potesse contenere l'allocazione di destinazione, corrompendo un oggetto adiacente.
XBOW ha predisposto l'heap circostante affinché la sovrascrittura modificasse un oggetto writer attivo. La catena ha quindi reindirizzato un flusso di controllo legittimo e avviato un processo al di fuori del sandbox.
Google ha corretto il difetto limitando il nuovo tentativo al minore di due valori: la richiesta originale o i byte rimanenti nella pagina sorgente.
La correzione ha eliminato la dipendenza di Crashpad dalla tempistica. Anche se un altro thread modifica la mappatura, il nuovo tentativo non può superare la destinazione del chiamante.
Questi meccanismi mostrano perché la catena richiedesse più della generazione generica di codice. Ogni fase richiedeva conoscenze sul comportamento del compilatore, sulla decodifica delle immagini, sul layout dell'heap e sulla semantica dei processi di Windows.
Gli agenti hanno contribuito a esplorare quello spazio enorme. I ricercatori umani hanno deciso quali risultati fossero affidabili, compatibili e degni di integrazione.
Il tema comune era la mutabilità nascosta dietro un'assunzione di permanenza. Un numero, un buffer d'immagine e un processo sospeso sono tutti cambiati dopo che il codice li aveva trattati come fissi.
Dolan-Gavitt sostiene che tali violazioni degli invarianti si adattino bene ai modelli linguistici di grandi dimensioni. I modelli possono collegare un'ampia conoscenza delle interfacce dei sistemi operativi con modelli riscontrati in un repository open source.
Resta un'ipotesi tratta da un solo progetto. Tuttavia, offre ai difensori una strategia di ricerca concreta: identificare ogni confine in cui un componente presume che un altro non possa cambiare stato.
Si è trattato di ricerca AI guidata da esseri umani, non di un hack autonomo
Definire il progetto pienamente autonomo cancellerebbe il giudizio degli esperti che ha selezionato i bersagli, scartato i percorsi deboli e salvato la catena dopo una collisione.
XBOW si descrive come un'azienda di sicurezza offensiva autonoma. Il suo annuncio accredita inoltre un ricercatore che ha lavorato con agenti durante la campagna premiata di sei giorni.
Entrambe le affermazioni possono essere accurate se l'autonomia descrive l'esecuzione dei compiti anziché la responsabilità dell'intero processo di ricerca. Gli agenti hanno completato una quantità sostanziale di lavoro tecnico senza richiedere codifica manuale a ogni passaggio.
Hanno esplorato l'albero dei sorgenti di Chrome, testato idee, realizzato proof of concept e prodotto le prime bozze di exploit. Sono parti significative della scoperta di vulnerabilità.
Dolan-Gavitt e altri ricercatori di XBOW hanno definito il contesto delle campagne. Hanno fornito esempi, messo alla prova gli output, reindirizzato le ricerche e selezionato i componenti da integrare.
Gli esseri umani hanno anche riconosciuto che la catena avrebbe dovuto usare interfacce pulite e backup. Questa scelta architetturale ha consentito al team di sostituire rapidamente la fase Gin duplicata.
Un modello da solo non ha deciso che il rischio di accettazione da parte di Google richiedesse vulnerabilità intercambiabili. La decisione rifletteva esperienza nei programmi di disclosure e nello sviluppo di exploit.
La ricerca precedente complica inoltre una lettura letterale di "sei giorni". XBOW ha iniziato a perseguire una catena completa per Chrome dopo una riunione aziendale a gennaio.
Secondo l'azienda, la sua prima catena ha richiesto due mesi. Lo sprint finale ha beneficiato di strumenti, lavoro non riuscito e conoscenze sui bersagli accumulati nel tempo.
Questo non rende falsa la cifra dei sei giorni. XBOW data chiaramente la costruzione della catena premiata dal 2 al 7 agosto.
Significa che la misurazione copre la campagna finale, non la creazione dell'intera capacità organizzativa che la sostiene. Questa distinzione conta nel valutare la replicabilità.
Un ricercatore di sicurezza capace non può necessariamente spendere lo stesso importo in API e riprodurre il risultato. XBOW mette esplicitamente in guardia da questa conclusione nel suo resoconto tecnico.
L'accesso al modello è solo un input. Esempi di alta qualità, strumenti di valutazione, conoscenza degli exploit e orchestrazione disciplinata influenzano tutti la capacità delle idee generate di superare i test.
Le prove pubbliche contengono anche un'incoerenza nell'etichettatura. L'annuncio di XBOW assegna CVE-2026-85045 alla fase WebP animata.
La sua analisi tecnica e le informazioni di rilascio di Google associano quell'identificatore al difetto di V8. La vulnerabilità WebP non ha un identificatore pubblico chiaramente confermato nei documenti disponibili.
Questa discrepanza non indebolisce la catena completa verificata. Mostra però perché i lettori dovrebbero separare la conferma tecnica dal testo rifinito di un annuncio.
Due vulnerabilità hanno identificatori pubblici chiari. CVE-2026-78952 riguarda il problema di Crashpad, mentre CVE-2026-85045 riguarda il problema di V8.
La fase WebP ha un problema Chromium pubblico e correzioni documentate. La sua etichetta CVE incerta non dovrebbe essere ripetuta come fatto assodato.
La cronaca indipendente di The Hacker News ha evidenziato la stessa incoerenza, confermando al contempo la sequenza più ampia e la correzione.
XBOW stima inoltre che il percorso vulnerabile abbia interessato un miliardo di utenti Chrome su Windows. Questa cifra sull'esposizione proviene dall'azienda, non da una misurazione pubblica di Google.
Una popolazione esposta non coincide con una popolazione compromessa. XBOW afferma di non aver trovato prove che qualcuno abbia usato queste vulnerabilità contro gli utenti di Chrome.
La conclusione più prudente è più circoscritta e più solida. Un modello pubblico di uso generale, guidato da specialisti, ha accelerato in modo sostanziale un exploit reale che Google ha riprodotto e premiato.
Questo risultato è più rilevante di un punteggio benchmark. È anche meno autonomo di quanto suggeriscano le sintesi più drammatiche.
La ricerca sulle vulnerabilità con l'AI crea un dilemma per i difensori
La stessa automazione che aiuta i fornitori a trovare percorsi di codice pericolosi può aumentare il numero di gruppi capaci che li cercano.
XBOW presenta il lavoro come prova che i difensori dovrebbero impiegare per primi agenti offensivi contro il proprio software. Questa argomentazione ha una forza pratica.
I fornitori di software dispongono del codice sorgente, di ambienti di test, della conoscenza dei sistemi e dell'autorità per correggere i problemi rilevati. Possono inoltre eseguire campagne continue senza oltrepassare i confini legali.
Gli attaccanti hanno vantaggi diversi. Non devono documentare i tentativi falliti, coordinare le correzioni o attendere una finestra di disclosure.
Con il miglioramento delle capacità dei modelli, il costo di esplorare codebase complesse diminuisce per entrambi i gruppi. Il risultato è un intervallo più breve tra l'introduzione di un difetto e la creazione di un exploit funzionante da parte di qualcuno.
Il programma di ricompense di Google cerca di reindirizzare questa capacità verso la disclosure coordinata. Un pagamento elevato rende la segnalazione di una catena più attraente della sua vendita o del suo utilizzo privato.
Le ricompense non possono assorbire ogni scoperta. I programmi impongono regole di ambito, requisiti di segnalazione e limiti ai bonus idonei.
Anche le collisioni indeboliscono l'incentivo. Se più sistemi di agenti convergono sullo stesso difetto, solo il primo segnalante idoneo riceve il pieno riconoscimento.
Questo crea un nuovo problema di ottimizzazione per i ricercatori. Trovare rapidamente vulnerabilità comuni conta, ma scoprire percorsi insoliti conta di più.
Il design modulare di XBOW ha risposto direttamente a questo contesto. Le fasi di backup hanno protetto la submission più ampia quando un componente è diventato non idoneo.
I difensori dovrebbero aspettarsi la stessa strategia da attaccanti ben finanziati. Lo sviluppo modulare di exploit consente a un gruppo di sostituire un componente corretto o già scoperto senza abbandonare un'intera campagna.
I sistemi di AI generano anche grandi volumi di risultati plausibili ma errati. I team di sicurezza che automatizzano la scoperta senza migliorare la validazione potrebbero creare rumore costoso.
Un proof of concept riduce questo problema perché trasforma un avviso astratto in un comportamento osservabile. Una catena completa va oltre, mostrando come debolezze separate si combinino.
Tuttavia, la generazione di exploit introduce rischi di governance. Durante i test, i modelli possono ricevere codice sorgente sensibile, dati di crash, credenziali o architetture interne.
Le organizzazioni necessitano di controlli per l'accesso ai dati, l'isolamento, il logging e la disclosure. Necessitano inoltre di un'autorità chiara su ciò che un agente può testare e su dove possano essere eseguiti gli exploit generati.
La revisione umana resta essenziale al confine tra ricerca e implementazione. Un agente in grado di modificare un exploit per browser non dovrebbe ottenere accesso illimitato ai sistemi di produzione.
OpenAI e altri fornitori di modelli affrontano un problema di policy correlato. Restrizioni rigide possono bloccare il legittimo lavoro difensivo, mentre un accesso ampio può espandere la capacità offensiva.
Secondo l'azienda, l'exploit Chrome GPT-5.6 di XBOW ha utilizzato un modello disponibile pubblicamente. Non ha richiesto un sistema specializzato riservato ai governi.
Questo dettaglio indebolisce le strategie basate esclusivamente sulla restrizione di uno specifico modello di sicurezza. Le capacità generali di programmazione e ragionamento supportano già la ricerca avanzata se abbinate al giusto harness.
I difensori necessitano quindi di risposte operative, non solo di dibattiti sull'accesso. Sviluppo più rapido delle patch, migliori confini del sandbox e test avversariali continui diventano più importanti.
I team devono inoltre preservare la conoscenza istituzionale. Log degli agenti, ipotesi fallite, ambienti di riproduzione e decisioni dei revisori costituiscono una risorsa di sicurezza riutilizzabile.
Una base di conoscenza ingegneristica ricercabile può aiutare i team a conservare questo contesto tra un incidente e l'altro. Non può sostituire l'esperienza sugli exploit, ma può ridurre il lavoro investigativo ripetuto.
La lezione più ampia non è che l'AI abbia reso automatica la sicurezza del software. Ha reso le operazioni di sicurezza disciplinate più preziose, perché la sperimentazione capace ora scala più rapidamente.
Cosa osservare dopo il premio di $250.000 di Google
Le prossime prove dovrebbero misurare ripetibilità, tempi di risposta difensiva e riduzione dell'intervento umano, anziché un'altra dimostrazione spettacolare.
Il primo segnale è se XBOW riuscirà a riprodurre questo risultato su bersagli di codice nativo non correlati. L'azienda afferma di stare sviluppando un prodotto autonomo per software desktop, server e sistemi embedded.
Una sola catena per browser premiata non può dimostrare una capacità generale. Scoperte ripetute su architetture diverse rafforzerebbero l'affermazione secondo cui l'orchestrazione degli agenti si trasferisce oltre Chrome.
La qualità di questi risultati conta più del numero grezzo di vulnerabilità. Risultati ad alta gravità con proof funzionanti e correzioni accettate forniscono prove più solide rispetto ad avvisi di scanner non verificati.
Il secondo segnale è il modo in cui i fornitori di browser cambiano i propri test interni. Google ha già adeguato i suoi programmi di ricompense a un'era di ricerca sulla sicurezza assistita dall'AI.
Il suo framework 2026 enfatizza segnalazioni riproducibili e ad alto impatto e offre fino a $250.000 per catene complete di Chrome idonee. Google ha inoltre discusso l'uso dell'AI per migliorare il proprio rilevamento delle vulnerabilità.
Osservate intervalli più brevi tra l'accettazione della segnalazione e correzioni stabili. Osservate anche modifiche architetturali che eliminano intere classi di assunzioni sugli stati mutabili.
Il terzo segnale è la riduzione del coinvolgimento umano nelle catene riuscite. XBOW prevede che gli agenti possano trovare autonomamente ciascuno dei tre tipi di bug entro un anno.
Questa affermazione richiede prove. Un sistema futuro dovrebbe scegliere bersagli promettenti, scartare percorsi falsi, gestire le collisioni e integrare le fasi con minore guida da parte di esperti.
Contare i proof of concept generati non sarebbe sufficiente. Il test più solido è se un agente possa produrre una catena nuova, confermata dal fornitore, in condizioni controllate e autorizzate.
I registri di disclosure possono rivelare i progressi senza esporre prematuramente dettagli pericolosi. Possono mostrare chi ha selezionato il bersaglio, quanto intervento si è verificato e quali fasi hanno richiesto correzioni da esperti.
I lettori dovrebbero inoltre osservare la congestione dei programmi di ricompense. Un maggior numero di segnalazioni duplicate indicherebbe che i sistemi automatizzati si stanno concentrando su modelli di codice simili.
Un'impennata di risultati accettati e non correlati suggerirebbe una copertura più ampia. Un'impennata di submission rumorose graverebbe invece sui team di risposta dei fornitori senza migliorare la sicurezza in modo proporzionale.
Per gli utenti, l'azione immediata è semplice. Chrome installa gli aggiornamenti automaticamente, ma le protezioni entrano in vigore solo dopo il riavvio del browser.
Le falle individuate sono state corrette nel ciclo di rilascio di Chrome 152. Gli utenti dovrebbero riavviare Chrome e verificare che non restino aggiornamenti in sospeso.
Per i responsabili della sicurezza, la domanda utile è più impegnativa: con quale rapidità il vostro team potrebbe convalidare e correggere una catena di exploit generata automaticamente contro il vostro software?
L’exploit di Chrome realizzato da XBOW GPT-5.6 non dimostra che i ricercatori umani siano obsoleti. Dimostra che un singolo ricercatore qualificato può dirigere molte più attività sperimentali rispetto a prima.
Questo cambiamento premia le organizzazioni che combinano l’accesso ai modelli con una solida revisione tecnica, test controllati e una rapida correzione. Saranno queste capacità, e non il solo nome del modello, a determinare chi trarrà vantaggio da una scoperta delle vulnerabilità più rapida.
