El exploit de Chrome de XBOW GPT-5.6 obtuvo la recompensa de $250,000 de Google por una cadena completa
XBOW creó una cadena de explotación de Chrome de tres vulnerabilidades en seis días y obtuvo la recompensa máxima de $250,000 de Google por una cadena completa. El exploit de Chrome de XBOW GPT-5.6 comenzó con JavaScript convencional y terminó con código ejecutándose fuera de todos los entornos aislados de Chrome en Windows.
Ese resultado no significa que un modelo de IA haya derrotado a Chrome de forma independiente. El investigador Brendan Dolan-Gavitt eligió los objetivos, aportó contexto, revisó los hallazgos y conectó las etapas del exploit. Los agentes que utilizaron el modelo gpt-5.6-sol de OpenAI, disponible públicamente, buscaron en el código fuente, probaron hipótesis y elaboraron pruebas de concepto.
La historia más relevante trata sobre la compresión del tiempo de investigación. XBOW afirma que un trabajo comparable antes requería cuatro especialistas y entre seis y nueve meses. Su cadena premiada surgió durante una campaña de agosto, después de que investigaciones previas, técnicas reutilizables y una cadena fallida prepararan el terreno.
Google reprodujo el exploit final, corrigió sus tres vulnerabilidades y aprobó la recompensa. Esos hechos llevan el proyecto más allá de una prueba de referencia privada. También revelan la verdadera presión competitiva: los defensores de navegadores deben enfrentarse ahora a investigación de vulnerabilidades a escala de máquina, guiada por humanos experimentados.
La cadena de seis días atravesó todos los entornos aislados de Chrome
El cambio decisivo no fue encontrar un único error de Chrome, sino conectar tres fallos independientes en una ruta verificada desde una página web hasta la ejecución de código en Windows.
XBOW creó la cadena premiada entre el 2 y el 7 de agosto de 2026, mientras los investigadores asistían a Black Hat y DEF CON en Las Vegas. La empresa divulgó el trabajo el 13 de octubre, después de que Google distribuyera las correcciones.
Una cadena completa combina vulnerabilidades que proporcionan capacidades diferentes. Cada etapa lleva al atacante más allá de un límite de seguridad independiente que un único fallo no puede atravesar por sí solo.
La primera etapa apuntó a V8, el motor de JavaScript de Chrome. Un error del compilador permitió al exploit obtener amplio acceso de lectura y escritura dentro de la región de memoria protegida de V8.
V8 coloca la mayoría de los objetos JavaScript dentro de un espacio de direcciones aislado de cuatro gibibytes. Este entorno aislado dentro del proceso limita a qué puede acceder un atacante tras corromper un objeto JavaScript.
La segunda etapa atacó la ruta de decodificación de WebP animado de Chrome. Convirtió el acceso a V8 en una escritura precisa fuera de esa región protegida, atravesando el primer límite importante.
La tercera etapa apuntó a Crashpad, el componente de informes de fallos de Chrome. Crashpad opera fuera del entorno aislado del renderizador porque debe inspeccionar procesos cuando fallan.
Esa vulnerabilidad final transformó la capacidad limitada de escritura en memoria en ejecución de código dentro del controlador de fallos no aislado. XBOW demostró el resultado iniciando la aplicación Calculadora de Windows desde una página normal de Chrome Beta.
El detallado análisis del exploit de Dolan-Gavitt documenta las tres etapas y sus interfaces. También describe los roles humanos y de las máquinas detrás del trabajo.
El ataque no requería una descarga ni un clic adicional después de cargar la página. Antes de su corrección, un sitio malicioso podría, en teoría, haber activado la cadena únicamente mediante contenido del navegador.
XBOW afirma que las vulnerabilidades nunca se utilizaron contra usuarios de Chrome. Las envió a través del Programa de Recompensas por Vulnerabilidades de Google, lo que dio a Google tiempo para reproducir y reparar los fallos antes de la publicación.
El rastreador público de incidencias de Google confirma de forma independiente el resultado más importante. Un ingeniero registró que el exploit inició Calculadora desde Chrome Beta, y el programa aprobó una recompensa de $250,000.
Esa verificación importa porque las demostraciones de las empresas pueden omitir limitaciones del entorno. Aquí, el registro de Google confirma que la cadena funcionó y cumplió los requisitos para su mayor bonificación por exploits de navegador.
La recompensa también fue el primer pago por una cadena completa bajo las reglas que Google introdujo en abril de 2026. Esas reglas reservan la cantidad máxima para un exploit que comienza con contenido web y compromete el proceso del navegador.
Google limita el programa a cuatro bonificaciones de este tipo durante 2026. Por ello, sus reglas del Chrome VRP consideran las cadenas funcionales como envíos escasos y de valor excepcional.
La cadena final no fue el primer intento de XBOW. Una ruta anterior dependía de una vulnerabilidad que Google ya conocía, lo que convertía ese componente en un duplicado e impedía optar a una nueva recompensa.
XBOW evitó perder todo el proyecto porque había separado el exploit en módulos intercambiables. Dolan-Gavitt y los agentes sustituyeron la etapa intermedia duplicada por el fallo de WebP animado.
Esa sustitución es central en la historia. El resultado dependió de un sistema de investigación reutilizable, no de un único prompt inspirado que produjera un exploit de la nada.
Por qué el exploit de Chrome de XBOW GPT-5.6 cambia la curva de costes
El resultado de seis días presiona a los proveedores de navegadores porque comprime la costosa labor de búsqueda, pruebas e integración que sustenta la explotación avanzada.
Una cadena completa de Chrome ha exigido tradicionalmente conocimientos poco comunes en compiladores, internals de navegadores, sistemas operativos y mitigaciones de exploits. Los investigadores deben encontrar fallos que sean a la vez novedosos y compatibles.
Después deben convertir errores aislados en capacidades estables. Una etapa puede exponer memoria, otra puede atravesar un entorno aislado y una tercera debe completar la ejecución de código.
XBOW afirma que un equipo de cuatro personas necesitaba aproximadamente entre seis y nueve meses para un trabajo similar antes de los grandes modelos de lenguaje. Su primera cadena completa interna llevó alrededor de dos meses.
La cadena premiada tardó seis días. XBOW reconstruyó su uso a partir de registros archivados de los agentes y calculó aproximadamente $40,000 en cargos de API para la campaña.
Esa comparación requiere una formulación cuidadosa. La campaña de seis días no partió de cero en cuanto a conocimiento organizativo. Siguió a meses de exploración y a una cadena completa anterior.
Los investigadores de XBOW también aportaron técnicas de explotación desarrolladas en proyectos previos. Los agentes podían recurrir a ejemplos de alta calidad, herramientas consolidadas y una arquitectura modular.
Incluso con esas salvedades, el cambio sigue siendo considerable. La experiencia reutilizable ahora puede replicarse entre sesiones de agentes en paralelo, en lugar de quedar limitada a la atención de un único investigador.
Los agentes realizaron búsquedas amplias en el código fuente, generaron hipótesis, escribieron programas de prueba y perfeccionaron las primeras etapas del exploit. Los humanos se concentraron en la estrategia, la validación y las decisiones que conectaban el trabajo.
Esta división cambia la economía de la investigación de vulnerabilidades. La revisión de código fuente y la iteración experimental pueden consumir enormes cantidades de tiempo experto, incluso cuando la mayoría de los intentos fracasan.
Los agentes pueden ejecutar varias campañas más acotadas a la vez. XBOW dividió el problema en descubrimiento de vulnerabilidades, corrupción de V8, escape del entorno aislado, escape del renderizador e integración final.
El paralelismo no garantiza el éxito. Aumenta la cantidad de rutas técnicamente plausibles que un humano puede inspeccionar dentro de un período fijo.
La recompensa de $250,000 superó la factura de API reportada en $210,000, antes de salarios, infraestructura y costes de investigación previos. Esa aritmética no establece un margen de beneficio repetible.
Las recompensas por errores dependen de la novedad, la gravedad, la reproducibilidad y el momento. Una vulnerabilidad técnicamente válida puede dejar de tener valor para quien la informa si otra parte la presentó antes.
La vulnerabilidad duplicada de Gin mostró ese riesgo durante este proyecto. Más investigadores automatizados que examinen el mismo código de código abierto probablemente aumentarán esas colisiones.
Google también utiliza técnicas asistidas por IA en su propio trabajo de seguridad. Por tanto, la competencia no consiste simplemente en atacantes de IA frente a defensores humanos.
Es una carrera entre organizaciones que pueden convertir modelos en sistemas de investigación fiables. La selección de objetivos, la gestión de evidencias, la reproducción y la disciplina de divulgación se convierten en factores diferenciadores.
Para los equipos de navegadores, una investigación externa más rápida genera presión operativa. Los proveedores deben reproducir informes, preparar correcciones, coordinar lanzamientos y evaluar código relacionado antes de que se difundan los detalles técnicos.
La presión se extiende más allá de Google. Cualquier empresa que distribuya una gran aplicación de código nativo afronta ahora una barrera de investigación más baja para hallar interacciones entre múltiples subsistemas.
El software de escritorio, los servidores y los dispositivos integrados contienen los mismos tipos de supuestos ocultos. Un componente confía en un valor que otro componente puede modificar inesperadamente.
El resultado de XBOW sugiere que esos supuestos entre componentes son objetivos especialmente productivos para la investigación asistida por IA. Los modelos pueden buscar ampliamente en el código fuente y conectar detalles de implementación poco evidentes.
Esa capacidad favorece a los defensores que pueden probar continuamente sus propios sistemas. También favorece a los atacantes que pueden permitirse campañas repetidas sin divulgar hallazgos fallidos o peligrosos.
Tres supuestos mutables hicieron posible el exploit
Cada etapa rompió un supuesto diferente que Chrome trataba como estable, lo que dio a los agentes un patrón técnico coherente que perseguir.
La primera vulnerabilidad apareció en Maglev, el compilador optimizador de nivel intermedio de V8. Maglev acelera JavaScript al establecer supuestos sobre las formas y los valores de los objetos.
Cuando un supuesto falla, V8 realiza una desoptimización. Reconstruye objetos JavaScript ordinarios y reanuda la ejecución en código menos especializado.
La ruta vulnerable reutilizaba un número encapsulado que debía haberse recreado por separado. Por ello, dos objetos reconstruidos podían compartir un valor mutable mientras la lógica del compilador lo trataba como inmutable.
El exploit modificó ese valor compartido entre dos observaciones. Una comprobación aprobó un índice de matriz seguro, mientras que una operación posterior utilizó el valor alterado como su desplazamiento real.
Esa discrepancia produjo acceso a memoria a través de la región aislada de V8. Desde JavaScript, el exploit podía inspeccionar punteros y manipular objetos dentro del entorno aislado.
La corrección de Google eliminó la reutilización insegura. V8 ahora materializa un nuevo número encapsulado para cada objeto relevante, en lugar de deduplicar el valor supuestamente constante.
La segunda vulnerabilidad explotó otro supuesto de propiedad. La interfaz WebCodecs de Chrome permite a JavaScript transferir un ArrayBuffer a un decodificador de imágenes.
Según la semántica normal de JavaScript, transferir ese búfer desvincula las vistas anteriores. El decodificador puede entonces tratar los bytes subyacentes como de propiedad exclusiva y estables.
Un atacante que ya controla el entorno aislado de V8 puede corromper la contabilidad que impone la desvinculación. XBOW mantuvo activa una vista después de que Chrome creyera que la transferencia se había completado.
El exploit colocó dos imágenes WebP animadas válidas de igual longitud en la misma memoria. Dejó que Chrome inspeccionara la geometría de una imagen y luego sustituyó los bytes por los de la otra.
El decodificador combinó dimensiones almacenadas en caché de la primera imagen con datos de píxeles de la segunda. Este fallo de comprobación temporal frente a uso temporal provocó un desbordamiento del heap nativo.
XBOW refinó el desbordamiento hasta obtener una escritura de 64 bits seleccionada en una dirección nativa seleccionada. Eso bastó para preparar código dentro del renderizador para el último cruce de límite.
La tercera vulnerabilidad involucraba la creencia de Crashpad de que un renderizador suspendido no podía cambiar. Crashpad pausa un proceso antes de leer su memoria para elaborar un informe de fallo.
Windows admite una marca especial de hilo que puede eludir la congelación de un proceso. XBOW creó un hilo de ese tipo y modificó los permisos de página mientras Crashpad realizaba dos lecturas relacionadas.
La primera lectura de Crashpad falló. Su lógica de recuperación infirió que los datos solicitados habían cruzado un límite de página y luego volvió a intentarlo con una longitud mayor.
El hilo exento de congelación hizo que la página de origen pudiera leerse antes del reintento. Crashpad copió más datos de los que podía contener la asignación de destino, corrompiendo un objeto adyacente.
XBOW organizó el heap circundante para que la sobrescritura modificara un objeto writer activo. La cadena redirigió entonces el flujo de control legítimo e inició un proceso fuera del sandbox.
Google corrigió el fallo limitando el reintento al menor de dos valores: la solicitud original o los bytes restantes en la página de origen.
La corrección eliminó la dependencia de Crashpad del tiempo. Aunque otro hilo cambie el mapeo, el reintento no puede exceder el destino del llamador.
Estos mecanismos muestran por qué la cadena requirió más que generación de código genérica. Cada etapa exigía conocimiento del comportamiento del compilador, la decodificación de imágenes, la disposición del heap y la semántica de procesos de Windows.
Los agentes ayudaron a explorar ese enorme espacio. Los investigadores humanos decidieron qué resultados eran fiables, compatibles y merecían integrarse.
El tema común era la mutabilidad oculta tras una suposición de permanencia. Un número, un búfer de imagen y un proceso suspendido cambiaron después de que el código los tratara como fijos.
Dolan-Gavitt sostiene que esas violaciones de invariantes se adaptan bien a los modelos de lenguaje grandes. Los modelos pueden conectar un conocimiento amplio de las interfaces de los sistemas operativos con patrones hallados en un repositorio de código abierto.
Eso sigue siendo una hipótesis derivada de un solo proyecto. Aun así, ofrece a los defensores una estrategia de búsqueda concreta: identificar cada límite en el que un componente supone que otro no puede cambiar de estado.
Esta fue investigación de IA dirigida por humanos, no un hackeo autónomo
Calificar el proyecto como plenamente autónomo borraría el juicio experto que seleccionó objetivos, descartó vías débiles y rescató la cadena tras una colisión.
XBOW se describe como una empresa autónoma de seguridad ofensiva. Su anuncio también acredita a un investigador que trabajó con agentes durante la campaña premiada de seis días.
Ambas afirmaciones pueden ser precisas si la autonomía describe la ejecución de tareas en lugar de la propiedad de todo el proceso de investigación. Los agentes completaron un trabajo técnico sustancial sin programación manual en cada paso.
Exploraron el árbol de código fuente de Chrome, probaron ideas, construyeron pruebas de concepto y produjeron borradores iniciales de exploits. Son partes significativas del descubrimiento de vulnerabilidades.
Dolan-Gavitt y otros investigadores de XBOW estructuraron las campañas. Aportaron ejemplos, cuestionaron las salidas, redirigieron las búsquedas y seleccionaron componentes para la integración.
Los humanos también reconocieron que la cadena debía usar interfaces limpias y respaldos. Esa decisión arquitectónica permitió al equipo sustituir rápidamente la etapa duplicada de Gin.
Un modelo por sí solo no decidió que el riesgo de aceptación por parte de Google exigía vulnerabilidades intercambiables. La decisión reflejaba experiencia con programas de divulgación y desarrollo de exploits.
La investigación anterior también complica una lectura literal de «seis días». XBOW comenzó a perseguir una cadena completa de Chrome tras una reunión de la empresa en enero.
Según la empresa, su primera cadena tardó dos meses. El sprint final se benefició de esas herramientas acumuladas, trabajo fallido y conocimiento del objetivo.
Esto no vuelve falsa la cifra de seis días. XBOW fecha claramente la construcción de la cadena premiada entre el 2 y el 7 de agosto.
Significa que la medición abarca la campaña final, no la creación de toda la capacidad organizativa que la sustenta. Esa distinción importa al evaluar la posibilidad de replicarla.
Un investigador de seguridad competente no necesariamente puede gastar la misma cantidad en API y reproducir el resultado. XBOW advierte explícitamente contra esa conclusión en su informe técnico.
El acceso al modelo es solo un insumo. Ejemplos de alta calidad, herramientas de evaluación, conocimiento de exploits y una orquestación disciplinada influyen en que las ideas generadas sobrevivan a las pruebas.
La evidencia pública también contiene una inconsistencia de etiquetado. El anuncio de XBOW asigna CVE-2026-85045 a la etapa WebP animada.
Su informe técnico y la información de lanzamiento de Google asocian ese identificador con el fallo de V8. La vulnerabilidad de WebP no tiene un identificador público claramente confirmado en los registros disponibles.
Esta discrepancia no socava la cadena completa verificada. Sí muestra por qué los lectores deben separar la confirmación técnica del texto pulido de un anuncio.
Dos vulnerabilidades tienen identificadores públicos claros. CVE-2026-78952 cubre el problema de Crashpad, mientras que CVE-2026-85045 cubre el problema de V8.
La etapa WebP tiene un problema público de Chromium y correcciones documentadas. Su etiqueta CVE incierta no debería repetirse como un hecho establecido.
La cobertura independiente de The Hacker News destacó la misma inconsistencia, a la vez que confirmó la secuencia más amplia y la corrección.
XBOW también estima que la vía vulnerable afectaba a mil millones de usuarios de Chrome en Windows. Esa cifra de exposición procede de la empresa, no de una medición pública de Google.
Una población expuesta no es lo mismo que una población comprometida. XBOW afirma que no encontró evidencia de que alguien utilizara estas vulnerabilidades contra usuarios de Chrome.
La conclusión más segura es más limitada y más sólida. Un modelo público de propósito general, guiado por especialistas, aceleró materialmente un exploit real que Google reprodujo y recompensó.
Ese resultado es más relevante que una puntuación de benchmark. También es menos autónomo de lo que sugieren los resúmenes más dramáticos.
La investigación de vulnerabilidades con IA crea un dilema para los defensores
La misma automatización que ayuda a los proveedores a encontrar rutas de código peligrosas puede aumentar el número de grupos capaces que las buscan.
XBOW presenta el trabajo como evidencia de que los defensores deberían desplegar primero agentes ofensivos contra su propio software. Ese argumento tiene fuerza práctica.
Los proveedores de software poseen código fuente, entornos de prueba, conocimiento del sistema y autoridad para corregir hallazgos. También pueden ejecutar campañas continuas sin cruzar límites legales.
Los atacantes tienen ventajas distintas. No necesitan documentar intentos fallidos, coordinar correcciones ni esperar una ventana de divulgación.
A medida que mejora la capacidad de los modelos, el coste de explorar bases de código complejas disminuye para ambos grupos. El resultado es un intervalo más corto entre la introducción de un fallo y el momento en que alguien desarrolla un exploit funcional.
El programa de recompensas de Google intenta redirigir esa capacidad hacia la divulgación coordinada. Un pago elevado hace que reportar una cadena sea más atractivo que venderla o usarla de forma privada.
Las recompensas no pueden absorber todos los descubrimientos. Los programas imponen reglas de alcance, requisitos de reporte y límites a las bonificaciones elegibles.
Las colisiones también debilitan el incentivo. Si varios sistemas de agentes convergen en un mismo fallo, solo el primer reportante que cumpla los requisitos recibe el crédito completo.
Esto crea un nuevo problema de optimización para los investigadores. Encontrar vulnerabilidades comunes con rapidez importa, pero descubrir rutas poco comunes importa más.
El diseño modular de XBOW respondió directamente a ese entorno. Las etapas de respaldo protegieron la presentación más amplia cuando un componente dejó de ser elegible.
Los defensores deberían esperar la misma estrategia de atacantes bien financiados. El desarrollo modular de exploits permite a un grupo reemplazar un componente corregido o descubierto sin abandonar toda una campaña.
Los sistemas de IA también generan grandes volúmenes de hallazgos plausibles pero incorrectos. Los equipos de seguridad que automaticen el descubrimiento sin mejorar la validación pueden generar ruido costoso.
Una prueba de concepto acota ese problema porque convierte una advertencia abstracta en un comportamiento observable. Una cadena completa va más allá al mostrar cómo se combinan debilidades separadas.
Sin embargo, la generación de exploits introduce riesgos de gobernanza. Los modelos pueden recibir código fuente sensible, datos de fallos, credenciales o arquitectura interna durante las pruebas.
Las organizaciones necesitan controles de acceso a datos, aislamiento, registro y divulgación. También necesitan una autoridad clara sobre qué puede probar un agente y dónde pueden ejecutarse los exploits generados.
La revisión humana sigue siendo esencial en la frontera entre investigación y despliegue. Un agente que puede modificar un exploit de navegador no debería obtener acceso sin restricciones a sistemas de producción.
OpenAI y otros proveedores de modelos afrontan un problema de política relacionado. Las restricciones estrictas pueden bloquear trabajo defensivo legítimo, mientras que un acceso amplio puede expandir la capacidad ofensiva.
Según la empresa, el exploit de Chrome de XBOW con GPT-5.6 utilizó un modelo disponible públicamente. No requirió un sistema especializado exclusivo para gobiernos.
Ese detalle debilita las estrategias basadas únicamente en restringir un modelo de seguridad limitado. La capacidad general de programación y razonamiento ya admite investigación avanzada cuando se combina con el entorno adecuado.
Por ello, los defensores necesitan respuestas operativas, no solo debates sobre acceso. El desarrollo más rápido de parches, mejores límites de sandbox y pruebas adversariales continuas se vuelven más importantes.
Los equipos también deben preservar el conocimiento institucional. Los registros de agentes, las hipótesis fallidas, los entornos de reproducción y las decisiones de los revisores conforman un activo de seguridad reutilizable.
Una base de conocimiento de ingeniería con capacidad de búsqueda puede ayudar a los equipos a conservar ese contexto entre incidentes. No puede reemplazar la experiencia en exploits, pero puede reducir el trabajo de investigación repetido.
La lección más amplia no es que la IA haya automatizado la seguridad del software. Ha hecho que las operaciones de seguridad disciplinadas sean más valiosas porque la experimentación capaz ahora escala más rápido.
Qué observar tras la recompensa de $250,000 de Google
La siguiente evidencia debería medir la repetibilidad, el tiempo de respuesta defensiva y una menor intervención humana, en lugar de otra demostración dramática.
La primera señal es si XBOW puede reproducir este resultado en objetivos de código nativo no relacionados. La empresa afirma que está desarrollando un producto autónomo para software de escritorio, servidores y sistemas embebidos.
Una sola cadena de navegador recompensada no puede establecer una capacidad general. Descubrimientos repetidos en arquitecturas diferentes reforzarían la afirmación de que la orquestación de agentes se transfiere más allá de Chrome.
La calidad de esos resultados importa más que el número bruto de vulnerabilidades. Los hallazgos de alta gravedad con pruebas funcionales y correcciones aceptadas aportan evidencia más sólida que alertas de escáner no verificadas.
La segunda señal es cómo los proveedores de navegadores cambian sus pruebas internas. Google ya ha ajustado sus programas de recompensas para una era de investigación de seguridad asistida por IA.
Su marco de 2026 enfatiza informes reproducibles y de alto impacto, y ofrece hasta $250,000 para cadenas completas de Chrome que cumplan los requisitos. Google también ha hablado de usar IA para mejorar su propia detección de vulnerabilidades.
Observe intervalos más cortos entre la aceptación de informes y las correcciones estables. Observe también cambios arquitectónicos que eliminen clases completas de supuestos sobre estados mutables.
La tercera señal es una menor intervención humana en cadenas exitosas. XBOW predice que los agentes podrían encontrar de forma independiente cada uno de los tres tipos de fallos en el plazo de un año.
Esa afirmación requiere evidencia. Un sistema futuro tendría que elegir objetivos prometedores, descartar rutas falsas, gestionar colisiones e integrar etapas con menos dirección experta.
Contar las pruebas de concepto generadas no sería suficiente. La prueba más sólida es si un agente puede producir una cadena novedosa y confirmada por el proveedor en condiciones controladas y autorizadas.
Los registros de divulgación pueden revelar avances sin exponer prematuramente detalles peligrosos. Pueden mostrar quién seleccionó el objetivo, cuánta intervención tuvo lugar y qué etapas requirieron corrección experta.
Los lectores también deberían vigilar la congestión de los programas de recompensas. Más informes duplicados indicarían que los sistemas automatizados se están concentrando en patrones de código similares.
Un aumento de hallazgos aceptados y no relacionados sugeriría una cobertura más amplia. Un aumento de envíos ruidosos, en cambio, sobrecargaría a los equipos de respuesta de los proveedores sin mejorar la seguridad de forma proporcional.
Para los usuarios, la acción inmediata es sencilla. Chrome instala las actualizaciones automáticamente, pero las protecciones solo entran en vigor después de reiniciar el navegador.
Las vulnerabilidades identificadas se corrigieron durante el ciclo de lanzamiento de Chrome 152. Los usuarios deben reiniciar Chrome y confirmar que no quede ninguna actualización pendiente.
Para los responsables de seguridad, la pregunta útil es más exigente: ¿con qué rapidez podría su equipo validar y corregir una cadena de exploits generada por una máquina contra su propio software?
El exploit de Chrome de XBOW GPT-5.6 no demuestra que los investigadores humanos sean obsoletos. Demuestra que un investigador cualificado puede dirigir muchos más experimentos que antes.
Este cambio favorece a las organizaciones que combinan acceso a modelos con una sólida revisión técnica, pruebas controladas y una rápida corrección. Esas capacidades, y no solo el nombre del modelo, determinarán quién se beneficia de un descubrimiento de vulnerabilidades más rápido.
