XBOW ha costruito un exploit full-chain per Chrome con un modello AI pubblico in sei giorni

Il 13 ottobre la startup di sicurezza XBOW ha pubblicato come il suo team di ricerca ha usato un modello OpenAI disponibile al pubblico — GPT-5.6 Sol e i suoi predecessori — per costruire un exploit full-chain funzionante su Chrome: la vittima apre una pagina web e un attaccante esegue codice sulla sua macchina Windows. Tre bug, sei giorni, circa 40.000 dollari di calcolo e i 250.000 dollari del premio massimo di Google. I bug ora sono corretti. L'economia che li ha prodotti no.

Notizia in evoluzione — pubblicata alle 13:40 (11:40 UTC) del 14 ottobre 2026. Aggiornata man mano che XBOW e Google pubblicano il write-up tecnico e le note di rilascio.

In breve

Cosa è successo	Un modello AI pubblico ha costruito un exploit full-chain funzionante su Chrome — esecuzione di codice remota su Windows aprendo una sola pagina web
Realizzato da	Il Native Team di XBOW (Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee, Willem Pinckaers)
Modello AI	OpenAI GPT-5.6 Sol (disponibile al pubblico) e predecessori, guidati da agenti AI sotto supervisione umana
Bug nella catena	Tre bug indipendenti; una prima catena è stata squalificata perché Google conosceva già uno dei suoi bug
Impegno / calcolo	Sei giorni (2–7 agosto 2026, Las Vegas); circa 40.000 dollari di calcolo del modello
Premio	250.000 dollari — il primo Chrome Full Chain Exploit Bonus pagato sotto le regole 2026 di Google
Sfruttata attivamente	No — è un risultato di ricerca; i bug sono stati segnalati a Google e corretti
Stato della correzione	Tutti e tre i bug confermati e corretti da Google; aggiornare Chrome e riavviarlo
Write-up ufficiale	XBOW, XBOW Built a Chrome Full-Chain Exploit (13 ottobre 2026)

Cosa ha fatto davvero XBOW

Il progetto è nato a gennaio durante un all-hands di XBOW a Malta, dove il team si è dato come obiettivo una full chain sul browser con scadenza al Black Hat. L'exploit è stato costruito in sei giorni, da domenica 2 a venerdì 7 agosto 2026, a Las Vegas durante Black Hat e DEF CON.

Una "full chain" su Chrome è il bersaglio difficile attorno a cui è pensato il programma bonus di Google: un exploit che deve produrre una fuga dalla sandbox "con dimostrazione di controllo dell'attaccante / esecuzione di codice fuori dalla sandbox", eseguito da remoto, con nessuna o molto limitata interazione dell'utente. In pratica significa concatenare un bug lato renderer — la primitiva di corruzione di memoria che ottieni dentro la scheda — con un secondo bug indipendente che rompe la sandbox e raggiunge il sistema operativo host. La catena premiata di XBOW usa tre bug, ciascuno progettato come stadio indipendente con un'alternativa di riserva. Un primo tentativo è stato squalificato perché Google conosceva già uno dei suoi bug; il team ne ha costruito uno nuovo.

La divisione del lavoro conta. Secondo XBOW, gli agenti AI hanno cercato nel codice sorgente di Chrome, testato idee, costruito proof of concept e redatto il codice iniziale dell'exploit; gli umani hanno definito la strategia, scelto su cosa concentrarsi, verificato il lavoro e reindirizzato gli agenti quando si bloccavano. È offesa autonoma con un umano nel loop, non un singolo prompt fortunato.

"L'abbiamo fatto in sei giorni," ha scritto XBOW, contrapponendo lo sforzo a quello di un "veterano di un'agenzia di intelligence a tre lettere" il cui team aveva speso sei mesi su un lavoro paragonabile.

Perché la notizia vera è "sei giorni e 40.000 dollari"

L'assegno da 250.000 dollari è ciò che cattura l'attenzione — pareggia il massimo che Google paga per una fuga dalla sandbox di Chrome, la stessa cifra che un ricercatore ha incassato nel 2025 per un singolo bug di fuga dalla sandbox in Mojo. Il costo di ingresso è la notizia. Le full chain sui browser sono state finora lavoro artigianale — appannaggio di un piccolo numero di ricercatori d'élite e di team statali ben finanziati, misurato in mesi di tempo specialistico. Un risultato in sei giorni per circa 40.000 dollari di calcolo, guidato da poche persone con un modello che chiunque può noleggiare, sposta quella capacità di diversi gradini più in basso nella piramide delle minacce.

	Prima (modello artigianale)	Ora (il run di XBOW)
Chi	Ricercatori d'élite, team statali	Un piccolo team che guida un modello pubblico
Tempo	Mesi	Sei giorni
Costo	Stipendi specialistici, talento raro	~40.000 dollari di calcolo
Scalabilità	Limitata dagli esperti umani	Limitata dal budget GPU

Quando il vincolo che lega lo sviluppo di exploit passa da competenza umana rara a budget GPU, il numero di attori capaci di produrre uno zero-day su browser sale e il time-to-exploit scende. È un cambiamento del modello di minaccia, non una notizia del giorno. Ha la stessa forma dell'AI che ha trovato nel kernel Linux un bug di root che nove anni di umani avevano mancato: la capacità di trovare non è più limitata da quanti esperti puoi assumere.

Il punto era il modello: pubblico, non un modello cyber riservato

XBOW è stata esplicita: non ha usato un modello di sicurezza specializzato o riservato, ma uno "disponibile a chiunque". È questo il dettaglio scomodo.

OpenAI distribuisce anche un modello offensivo dedicato, GPT-5.6-Cyber, costruito sulla stessa base GPT-5.6 Sol e riservato dietro il livello di accesso vagliato "Daybreak Red". Sul benchmark interno di OpenAI su catene di exploit, bypass di autenticazione ed escalation di privilegi, quel modello cyber ha risolto il 95% delle richieste contro l'1,5% del modello standard con i guardrail, e i ricercatori di OpenAI lo hanno usato per trovare due falle in V8 corrette da Google come CVE-2026-15903. La scommessa implicita sulla sicurezza è che tenere il modello affilato dietro un vaglio contenga la capacità.

XBOW ha appena costruito una full chain su browser senza il modello riservato. Mettere dietro un cancello la versione "cyber" non rimette la capacità nella scatola quando il modello base — quello che tutti possono chiamare — basta già con la giusta impalcatura intorno.

Remediation

È un risultato di ricerca, non sfruttamento in corso, e la correzione è davvero semplice. L'esposizione non sono i bug: è quanto lentamente un parco macchine applica davvero la correzione.

1. Sono interessato? Qualsiasi utente Chrome su una build rilasciata prima della correzione. I browser basati su Chromium (Microsoft Edge, Brave, Opera, Vivaldi) condividono lo stesso motore ed ereditano queste classi di bug quando arrivano i merge upstream. Verifica la versione da chrome://settings/help (mostra la build corrente e se è in sospeso un aggiornamento); controlla il parco macchine dalla console di gestione invece di fidarti dei singoli utenti.
2. Applica la patch — e riavvia. Conferma che Chrome sia sull'ultimo canale Stable. Chrome scarica gli aggiornamenti in background ma non li applica finché il browser non viene riavviato: un installer "aggiornato" con un processo in esecuzione da 20 giorni è ancora vulnerabile. Forza il riavvio via policy (RelaunchNotification / RelaunchNotificationPeriod) invece di aspettare gli utenti.
3. Non puoi riavviare ovunque subito? Per una catena renderer-più-fuga-dalla-sandbox non esiste un vero controllo compensativo diverso dalla patch — la Site Isolation è già attiva di default e non ferma questo. Riduci l'esposizione sugli endpoint in ritardo: limita la navigazione ad alto rischio, tieni gli utenti fuori dai privilegi di amministratore locale dove puoi, dai priorità agli host esposti su internet e di alto valore.
4. Caccia. Non esistono IOC del vendor, perché non è stato usato contro nessuno — non lasciare che uno strumento inventi percorsi o hash qui. I segnali generalizzabili per qualsiasi sfruttamento del browser sono il browser che genera processi figli inattesi, un gruppo di crash del renderer, o esecuzione di codice dopo una fuga dalla sandbox. Mappa le rilevazioni su MITRE ATT&CK T1189 (Drive-by Compromise), T1203 (Exploitation for Client Execution) e T1068 (Exploitation for Privilege Escalation).
5. Verifica. Dopo che il parco si è riavviato, conferma la build in esecuzione ovunque — poi misura quanto tempo ci è voluto. Quel numero è la tua finestra reale contro il prossimo zero-day su browser, ed è la cosa che vale la pena correggere.

Cosa non si sa ancora

• I tre identificativi CVE e la build esatta di Chrome corretta non sono nel post di XBOW, che rimanda a un write-up tecnico di accompagnamento di Brendan Dolan-Gavitt per il dettaglio a livello di bug. Verifica i dati puntuali sul blog Chrome Releases prima di trattare un qualsiasi CVE come parte di questa catena.
• Se i bug della catena si sovrappongano ad altri problemi recenti di Chrome trovati con l'AI (come CVE-2026-15903, trovato separatamente con il GPT-5.6-Cyber riservato) non è dichiarato: trattali come distinti finché il post tecnico non dice il contrario.
• L'esatta orchestrazione degli agenti — quanti agenti, quali strumenti, come sono stati valutati i run — attende il write-up tecnico.

La mossa del difensore: fai prima tu la stessa offesa

Se un piccolo team può guidare un modello pubblico a una full chain su Chrome in sei giorni, l'ipotesi di pianificazione onesta è che qualcuno punterà la stessa classe di capacità sul tuo software e sul tuo perimetro. La risposta difensiva non è sperare che il modello resti riservato — XBOW ha appena mostrato che non è necessario che lo sia. È eseguire quell'offesa contro te stesso, per primo, in continuazione.

È ciò per cui Zero Hunt è costruito: un red team AI autonomo il cui swarm a 10 agenti fa il fingerprinting di ogni bersaglio e scrive un exploit fresco e specifico per quel target con un modello locale, poi il suo agente di coding sigillato itera un proof-of-concept eseguibile finché non funziona in modo dimostrabile — lo stesso ciclo "costruisci la catena, non richiamarla", con ogni skill ricollaudata nell'AI Gym prima di toccare la produzione. Gira on-premise su modelli privati (ZeroHunt Apex e Apex Pro), così nulla del tuo ambiente lascia l'apparato e nessun fornitore può rallentare, rifiutare o revocare la capacità — l'opposto di dipendere da un livello di accesso riservato controllato da altri. Ogni exploit gira in un container effimero e un umano nel loop autorizza ogni azione che conta, con ogni evidenza firmata al momento della scrittura per la catena di custodia. Se vuoi questo puntato sulla tua superficie d'attacco invece di leggerlo dopo il pagamento di una taglia, è penetration testing automatizzato fatto come lo fanno ora gli attaccanti — guarda la piattaforma o scrivici.