Chrome: cadena de 250.000 dólares creada con IA en seis días

Un equipo de investigadores de XBOW, empresa estadounidense que hace pruebas de penetración con inteligencia artificial, ha construido una cadena de exploits completa (full-chain) contra Google Chrome en Windows: desde una página web maliciosa hasta la ejecución de código en el ordenador, fuera de todos los sandbox del navegador. Lo hicieron en seis días, con unos 40.000 dólares en costes de cómputo y con GPT-5.6 Sol, un modelo de OpenAI disponible al público. Google corrigió las tres vulnerabilidades y pagó una recompensa de 250.000 dólares.

A principios de octubre ARX News contó la pausa del OSS VRP de Google, desbordado por informes automáticos no válidos. Este caso muestra la otra cara del mismo fenómeno: la IA, guiada por personas expertas, también produce resultados de primer nivel.

Qué ha pasado

Las fuentes coinciden en los hechos principales: tres zero-day en Chrome, un modelo público de OpenAI, seis días de trabajo, 40.000 dólares de costes, 250.000 dólares de recompensa. Según The Register, el trabajo se hizo durante las conferencias Black Hat y DEF CON y la recompensa es la máxima que prevé Google para una full-chain de Chrome; CSO Online añade que es la primera pagada con las reglas de 2026 del programa. XBOW calcula que la cadena podía afectar a cerca de mil millones de usuarios de Windows.

Según CSO Online, los investigadores eligieron un modelo generalista, y no una herramienta especializada, precisamente para mostrar qué se puede lograr con un modelo público. The Register recoge el reparto de tareas que describe Brendan Dolan-Gavitt, uno de los cuatro investigadores, en el informe técnico de XBOW:

• los agentes de IA buscaron en el código fuente de Chrome, comprobaron las hipótesis del equipo y desarrollaron las pruebas de concepto y cada fase del exploit;
• las personas eligieron dónde buscar, aportaron el contexto, cuestionaron los resultados de los agentes y decidieron qué componentes encadenar. «Aplicamos una buena dosis de nuestra propia experiencia y criterio», escribió Dolan-Gavitt.

La cadena de ataque

Chrome aísla el código en dos niveles: el sandbox de V8 contiene los efectos de los fallos de memoria del motor JavaScript dentro del proceso renderer, y el sandbox del sistema operativo limita a su vez al renderer. Salir del primero no da automáticamente la ejecución de código nativo; salir del segundo significa llegar al sistema. Según el informe recogido por The Register, la cadena supera ambas barreras en tres pasos:

1. Maglev, el compilador optimizador de nivel intermedio de V8: un número «boxed» mutable reutilizado durante la desoptimización da lectura y escritura en toda la jaula de compresión de punteros de V8;
2. decodificación de imágenes WebP animadas: un fallo usado para salir del sandbox de V8, no atacando el sandbox en sí, sino una propiedad que el sandbox no garantiza a propósito y que Blink, el motor de renderizado, consideraba fiable;
3. Crashpad, el componente que recoge los datos de los fallos: un desbordamiento usado para superar el sandbox del proceso y ejecutar código en el sistema sin restricciones.

CSO Online describe el resultado final como el inicio de una aplicación de Windows desde una página web maliciosa. Las fuentes no indican los números CVE de las tres vulnerabilidades ni hablan de explotación real: se trata de una investigación comunicada a Google.

En términos de MITRE ATT&CK, una cadena así usada en un ataque correspondería a un compromiso durante la navegación (T1189, Drive-by Compromise) seguido de la ejecución de código en el cliente aprovechando el navegador (T1203).

Qué cambia para quien defiende

Lo importante no es esta cadena, ya corregida, sino los tiempos y los costes. El consejero delegado de XBOW, Oege de Moor, cuenta que según un antiguo miembro de una agencia de inteligencia un trabajo parecido requería seis meses; aquí bastaron seis días. Dolan-Gavitt concluye que para quien ataca con modelos de lenguaje «el listón está mucho más bajo» e invita a defenderse en consecuencia.

Para las empresas europeas e italianas esto significa una ventana más corta entre la publicación de una corrección y la aparición de exploits funcionales. El navegador es el software más expuesto de cada puesto de trabajo, también en los centros sanitarios y en los entornos compartidos. Para las entidades sujetas a NIS2, la gestión de las actualizaciones forma parte de las medidas de gestión del riesgo: si los tiempos de parcheo de los navegadores se miden en semanas, hay que revisarlos.

Qué hacer ahora

1. Comprueba la versión de Chrome: según The Register necesitas la 152.0.7977.82 o posterior. Revisa el inventario de todos los puestos Windows, no solo de los gestionados de forma centralizada.
2. Impón el reinicio del navegador: Chrome se actualiza solo, pero la corrección solo se aplica cuando se vuelve a abrir. Usa las políticas de gestión para pedir y después forzar el reinicio en un plazo fijado.
3. Revisa los demás navegadores basados en Chromium: las fuentes no dicen si otros fabricantes han integrado ya las correcciones ni cuándo. Sigue sus avisos.
4. No desactives el sandbox (por ejemplo con --no-sandbox en quioscos, automatizaciones o aplicaciones integradas): es justo la barrera que obliga a quien ataca a construir una cadena.
5. Vigila los procesos que inicia el navegador: una aplicación lanzada de forma inusual por un proceso de Chrome es una señal que debes investigar con tu solución antivirus/EDR.
6. Acorta los tiempos de parcheo de los navegadores y trátalos como los del sistema operativo: con la IA, el tiempo entre corrección y exploit puede reducirse.

Cómo ayuda ARXDOME

ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, con su antigüedad y destacando las ya explotadas: te ayuda a encontrar los puestos con un navegador desactualizado. ARX Sentry recoge el inventario de software y procesos de ordenadores y servidores y señala las ejecuciones sospechosas, útiles para reconocer procesos anómalos iniciados por el navegador.

Última actualización: 16 de octubre de 2026