Una IA de OpenAI ha encontrado dos fallos nuevos en Chrome: acepta el 95% de lo que el modelo normal rechaza

OpenAI ha presentado hoy GPT-5.6-Cyber, un modelo entrenado a propósito para buscar vulnerabilidades y construir cadenas de exploits. Lo llamativo no es que exista, sino lo que han decidido hacer con él: en el test interno con el que OpenAI mide cuántas peticiones sensibles completa un modelo —desarrollo de cadenas de exploits, saltarse la autenticación, escalada de privilegios—, GPT-5.6-Cyber responde al 95%. El mismo modelo base con las salvaguardas de siempre, GPT-5.6 Sol, responde al 1,5%.

Han bajado el nivel de rechazo a conciencia. A cambio, han subido el listón de quién entra: GPT-5.6-Cyber no está en ChatGPT ni en la API abierta. Solo se sirve a través de Daybreak Red, el nivel alto del programa de acceso verificado que OpenAI mantiene para profesionales de ciberseguridad, con verificación de identidad, requisitos de seguridad de cuenta, monitorización, restricciones de uso y declaraciones legales firmadas.

Para enseñar que la cosa funciona, lo pusieron a mirar V8, el motor de JavaScript de Chrome. Encontró dos vulnerabilidades que nadie conocía y que, encadenadas, permitían corromper memoria y escapar del sandbox del heap de V8. OpenAI las validó y se las pasó a Google por divulgación coordinada el 6 de julio. Google publicó el parche el 16 de julio y una de ellas tiene ya número propio: CVE-2026-15903. Si tu Chrome está en la versión 150.0.7871.128 o posterior, esto ya está arreglado en tu ordenador. No hay nada que hacer más allá de comprobar que el navegador está al día.

Qué es GPT-5.6-Cyber y quién puede tocarlo

El programa Daybreak tiene dos niveles y la diferencia entre ellos es justo el asunto de esta noticia. Daybreak Blue es el de entrada: da acceso a GPT-5.6 Sol con las salvaguardas ajustadas para trabajo defensivo autorizado —descubrimiento de vulnerabilidades, revisión de código, análisis de malware, respuesta a incidentes, validación de parches— y completa el 2% de las peticiones ofensivas. Daybreak Red es el nivel alto y es donde vive GPT-5.6-Cyber. Las cifras, ordenadas:

Configuración	Peticiones ofensivas completadas
GPT-5.6-Cyber (Daybreak Red)	95%
GPT-5.5-Cyber (modelo anterior)	57,3%
GPT-5.6 Sol vía Daybreak Blue	2%
GPT-5.6 Sol con salvaguardas estándar	1,5%

El salto del 57,3% al 95% respecto al modelo cyber anterior es la noticia técnica. El contraste entre el 95% y el 1,5% es la de fondo: es la distancia exacta entre lo que un modelo puede hacer y lo que se le deja hacer, y OpenAI acaba de cerrarla para un grupo concreto de gente con nombre y apellidos verificados.

Los dos modelos —Sol y Cyber— han alcanzado el umbral "alto" de capacidad en ciberseguridad dentro del marco de preparación de OpenAI, sin llegar al crítico. Como medida adicional, desde el 1 de septiembre todas las cuentas de Daybreak tendrán que usar llaves de seguridad por hardware.

Qué es el sandbox de V8 y por qué te importa aunque solo uses Chrome para leer el periódico

Esta parte merece explicarse bien, porque es donde la cobertura se pone dramática sin motivo.

V8 es el motor que ejecuta el JavaScript de las páginas web dentro de Chrome, y dentro de Edge, Brave, Opera y todo lo que va sobre Chromium. Cada vez que abres una web, esa web te manda código y tu navegador lo ejecuta. Es la premisa entera de internet: ejecutas programas de desconocidos decenas de veces al día, sin pensarlo.

Para que eso no sea un suicidio, Chrome mete capas. Una de ellas es el sandbox de V8: una región aislada por software donde vive la memoria del motor de JavaScript, activa por defecto en el Chrome de 64 bits desde hace años. Su trabajo no es evitar que aparezcan fallos en V8 —van a aparecer siempre, es un compilador que optimiza código sobre la marcha—, sino evitar que un fallo se convierta directamente en algo útil para el atacante. Si una web maliciosa corrompe memoria dentro de V8, el sandbox hace que esa corrupción se quede ahí dentro, sin poder saltar a leer y escribir en el resto del proceso.

Lo que encontró GPT-5.6-Cyber fueron dos fallos que, juntos, rompían esa contención. CVE-2026-15903, el único de los dos con identificador público, es de severidad alta: el compilador optimizador de V8 se saltaba una comprobación de seguridad al convertir un valor a entero, y el resultado era una lectura y escritura fuera de límites.

Y ahora la parte que hay que decir con claridad, porque se confunde todo el rato: escapar del sandbox de V8 no es escapar de Chrome. Salir de ahí te deja dentro del proceso de renderizado, que a su vez está encerrado por el sistema operativo en un sandbox de proceso y separado del resto de pestañas por el aislamiento de sitios. Para llegar a tus ficheros harían falta más eslabones. Lo que sí significa es que desaparece una capa entera de las que te protegen y que, a partir de ahí, el resto de la cadena sale mucho más barata. Por eso Google lo clasifica como severidad alta y por eso lo parchea rápido.

El parche llegó en la actualización estable de Chrome del 16 de julio, la 150.0.7871.128 (y .129 en Windows y Mac), junto a otros seis fallos, tres de ellos críticos. Google no ha reportado explotación en el mundo real de ninguno.

Qué es una divulgación coordinada, y por qué esta noticia llega hoy y no en julio

La secuencia de fechas no es casual. OpenAI reportó el fallo a Google el 6 de julio, Google lo parcheó el 16 y OpenAI lo ha contado el 11 de agosto. Eso es una divulgación coordinada: la norma no escrita que sostiene buena parte de la seguridad informática.

El acuerdo es simple. Quien encuentra un fallo se lo comunica en privado al fabricante y le da un plazo razonable para arreglarlo antes de publicar nada. El fabricante parchea y distribuye. Solo después se hacen públicos los detalles, con el CVE asignado y el crédito a quien lo encontró. Lo contrario —publicarlo en cuanto lo tienes— se llama full disclosure y deja a millones de usuarios expuestos mientras el fabricante corre.

Aquí funcionó como está escrito en el manual: diez días del aviso al parche, casi un mes más para que la actualización llegara a los ordenadores de la gente, y solo entonces el anuncio. Si esto te llega hoy como noticia, es porque ya está resuelto.

Cinco en un móvil, tres en una base de datos, cuatrocientas en un kernel

Chrome es el ejemplo que se puede contar porque ya está parcheado. El resto del inventario que OpenAI atribuye al modelo va sin nombres: al menos cinco vulnerabilidades en un sistema operativo móvil popular, tres fallos críticos en una base de datos muy usada y más de 400 problemas de escalada de privilegios en el kernel de un sistema operativo popular. OpenAI dice estar trabajando con socios y con la comunidad de código abierto para divulgarlos y remediarlos.

Ese "más de 400" es el número que hay que mirar dos veces. No porque cada uno sea grave —la escalada de privilegios en un kernel abarca desde lo trivial hasta lo serio—, sino por el cambio de escala. Encontrar vulnerabilidades ha sido siempre un trabajo caro, lento y hecho por muy poca gente. Cuando el coste de una revisión exhaustiva baja de meses de un especialista a horas de cómputo, el cuello de botella se muda: ya no está en encontrar los fallos, sino en parchearlos y en que los parches lleguen. Y esa segunda parte sigue siendo tan lenta como siempre. El panorama completo lo tengo en IA, ciberseguridad, amenazas y defensa.

Lo que de verdad se ha decidido aquí

La capacidad de encontrar un fallo y la de explotarlo son la misma capacidad. No hay una versión defensiva y otra ofensiva de "leer un compilador y darte cuenta de que esta conversión a entero no comprueba lo que debería". Es el mismo trabajo; lo que cambia es lo que haces después.

La respuesta de la industria a ese problema ha sido, hasta ahora, enseñar a los modelos a decir que no. Funciona a medias y molesta a quien tiene motivos legítimos: cualquiera que haya intentado usar un modelo generalista para trabajo de seguridad real conoce la frustración de que te niegue una petición perfectamente legal. Ese rechazo es, además, el motor de todo un mercado paralelo de modelos sin censura y de gente que se monta modelos abiertos en su propio equipo, donde no hay puerta ni portero.

Lo que hace OpenAI es cambiar de eje: en vez de restringir la capacidad, restringe el acceso. El modelo dice que sí casi siempre, pero solo a personas identificadas, monitorizadas y con responsabilidad legal encima. Es honesto respecto al problema real, que nunca fue el modelo sino quién está al otro lado del teclado.

Y traslada el riesgo entero a un sitio nuevo: el proceso de verificación. Todo depende de que ese filtro no se pueda comprar, suplantar ni comprometer. De ahí las llaves hardware obligatorias desde septiembre. Es una mitigación seria, pero convierte a Daybreak Red en un objetivo muy goloso.

Qué mirar a partir de ahora

Dos cosas. Si aparecen más CVE atribuidos al modelo en las próximas semanas, ese goteo dirá si el 95% se traduce en hallazgos sostenidos o si Chrome fue la demo de lanzamiento. Y si Google, Anthropic y el resto abren niveles equivalentes, el acceso verificado pasa a ser el estándar del sector en lugar de una excentricidad de OpenAI.

Mientras tanto, lo tuyo cabe en una línea: abre Chrome, entra en Ayuda, Información de Google Chrome, y comprueba que estás en la 150.0.7871.128 o posterior. Si el navegador se ha actualizado solo desde mediados de julio —lo normal—, ya lo estás.

---

Fuentes: el anuncio de OpenAI (fuente primaria); cobertura de Help Net Security, VentureBeat, Cyber Security News y GBHackers; ficha del fallo en el NVD y detalle de la actualización estable de Chrome del 16 de julio; documentación oficial del sandbox de V8.