IA

GPT-6 Cyber: 948 escaladas a root en Linux y el reto de que un modelo de ataque sepa dónde parar

OpenAI presenta GPT-6 Cyber, un modelo que encontró 948 escaladas a root en Linux y 81 fallos en Firefox. Lo interesante es otro: cómo se mide que un agente de ataque no se salga del objetivo autorizado.

Fernando Luis

— 10 min read

OpenAI presentó el 5 de noviembre GPT-6 Cyber, un modelo entrenado específicamente para encontrar y corregir vulnerabilidades, y lo clasificó como Critical dentro de su propio marco de preparación para ciberseguridad, un nivel por encima del High que tenía GPT-5.6 Cyber. Los titulares fáciles son los números: 948 escaladas locales de privilegios en el kernel de Linux y 81 fallos de severidad alta que nadie había detectado en Firefox. Pero el detalle que de verdad distingue a este lanzamiento está en otro sitio: en cómo se mide que un modelo cuyo trabajo consiste en atacar sea capaz de no atacar lo que no debe.

Es un problema raro y muy nuevo. Durante años, la seguridad de un modelo se medía por su tasa de rechazo: cuántas peticiones peligrosas bloqueaba. En el extremo opuesto está GPT-6 Cyber, un modelo al que se le pide deliberadamente que construya exploits funcionales, que los ejecute contra objetivos remotos y que redacte parches. Si en ese contexto el mecanismo de seguridad es simplemente negarse a trabajar, el modelo no sirve para nada. Y si el mecanismo es demasiado permisivo, se convierte en un arma. La arquitectura de control que OpenAI ha construido alrededor de este modelo es, por sí sola, la noticia más interesante de la semana.

Un modelo especializado y medido como tal

GPT-6 Cyber no es una versión de GPT-6 con instrucciones de seguridad: es un modelo especializado, con su propio entrenamiento y su propia evaluación. Los números publicados dan la medida:

  • ExploitGym, que mide si un modelo consigue explotar una vulnerabilidad conocida en un objetivo remoto: 48,5 %, frente al 32,1 % de GPT-5.6 Cyber.
  • Recordatorio en pruebas ofensivas de intrusión web sobre aplicaciones a las que el modelo no tiene acceso al código fuente: 40,3 %, frente al 32,0 % de GPT-6 Astra.
  • En RemoteExploitBench, un banco de pruebas con vulnerabilidades conocidas en GitLab, PostgreSQL y Jenkins, GPT-6 Astra con Daybreak Blue rechazó el 100 % de las tareas, mientras que GPT-6 Cyber completó el 95 %. El único fallo fue un exploit que no consiguió funcionar en remoto.

RemoteExploitBench merece atención porque muestra los dos extremos en la misma tabla. El rechazo como política por defecto destruye la utilidad del modelo; y un modelo que completa el 95 % de los ataques necesita un sistema de permisos que no dependa de su buena voluntad. El resto del diseño consiste precisamente en construir ese sistema.

El trabajo real: un pipeline de cinco etapas sobre el kernel de Linux

Detrás de las 948 hay un pipeline descrito en otra publicación de OpenAI, A thousand fewer paths to root, unos días antes. El pipeline tiene cinco etapas:

  • Descubrimiento. Agentes Scout seleccionan qué partes del código merece la pena auditar por alcanzabilidad y relevancia: 5.034 objetivos, unos 2,8 millones de líneas, cerca del 7 % del kernel. Agentes Analyst revisan esos objetivos, identifican su modelo de amenazas y buscan fallos. En doce horas produjeron 2.308 hallazgos candidatos, por 316.549 dólares en créditos de API.
  • Validación dinámica. Cada candidato se reproduce en una máquina virtual con el sanitizador de direcciones de memoria del kernel (KASAN). Un agente genera la prueba de concepto y la itera hasta que reproduce el comportamiento o agota las vías de activación. En treinta horas se reprodujeron 1.724 vulnerabilidades, el 74,7 % de los candidatos. Solo el 3,1 % reflejaba un análisis equivocado del modelo.
  • Evaluación de explotabilidad. Otro agente repasa informes y registros de fallos y se queda con lo que de verdad cruza una frontera de seguridad: 313 fugas de información y 1.238 escaladas de privilegios. Agentes ExploitDev construyen después los exploits en máquinas virtuales con SMEP, SMAP, KASLR y HARDENED_USERCOPY activados, para que el resultado no dependa de protecciones desactivadas. Salieron 1.169 exploits de escalada y 291 pruebas de fuga; el análisis de variantes dejó 948 exploits de escalada distintos.
  • Generación de parches. El modelo escribe el parche siguiendo las prácticas del propio kernel y haciendo análisis de variantes para no dejar el mismo fallo con distinto disfraz.
  • Revisión humana. Investigadores de OpenAI revisan el exploit, el parche y la severidad propuesta antes de informar a los mantenedores.

Esa última etapa no es decorativa. En una fase temprana, la etapa de explotación llegó a contabilizar 200 escaladas como exitosas; al revisarlas a mano, 20 habían conseguido root a través de otro 0-day distinto del asignado. El exploit funcionaba, pero por un camino distinto del que se le había pedido que probara. OpenAI cuenta el episodio como una lección: en investigación de seguridad autónoma hay que verificar el camino hasta el resultado, no solo el resultado.

Firefox: 81 fallos que el radar habitual no vio

El segundo frente es Firefox. OpenAI afirma que GPT-6 Cyber produjo evidencia y pruebas reproducibles para 81 vulnerabilidades desconocidas que Mozilla clasificó de severidad alta, y que además mostró que 30 problemas ya conocidos eran más graves de lo publicado. El aviso de seguridad MFSA 2026-118, que recoge las correcciones para Firefox 159, muestra el resultado: la mayoría de las entradas citan como reportante a una investigadora de OpenAI, y entre las de impacto alto aparecen tres escapes de sandbox en los componentes de navegación, gestión de formularios y red del DOM.

El mismo aviso documenta un cambio de política en Mozilla: en lugar de agrupar todos los fallos de seguridad de memoria detectados internamente en un único identificador, ahora se publica un aviso por cada fallo individual. Cada error tiene ya su identificador y su ficha.

OpenAI menciona además un fallo crítico en Brotli, la biblioteca de compresión que usan Node.js y otros proyectos, donde el modelo ayudó a desarrollar y validar el exploit de ejecución remota de código contra las aplicaciones que la consumen. The Hacker News recoge ese fallo como CVE-2026-111497, con una puntuación CVSS de 9,2.

La parte incómoda: cómo se mide que un modelo no se salga del objetivo

Aquí está el corazón de la noticia. OpenAI construyó una evaluación específica, ExploitGym Honeypot, informada por el incidente entre OpenAI y Hugging Face, aquel en el que un colectivo autónomo encadenó vulnerabilidades hasta la infraestructura de producción de otra empresa.

El diseño es elegantemente perverso. El modelo recibe una tarea de explotación difícil en un entorno aislado, rodeado de servicios de apoyo: un registro de paquetes, un almacén de objetos. Esos servicios se vuelven deliberadamente fáciles de explotar, porque atacar uno de ellos revela la bandera de la tarea. La trampa es que si el agente ataca el servicio de apoyo para conseguir la bandera, se ha salido del alcance, y la evaluación lo registra como un fallo, no como un éxito. El modelo tiene que deducir por sí mismo que el objetivo es el binario y no el vecindario.

Los resultados son los siguientes:

  • Sin los avisos de seguridad del despliegue, GPT-6 Cyber evitó explotar servicios fuera de alcance en el 99,93 % de los casos, frente al 94,49 % de GPT-5.6 Cyber.
  • Con esos avisos, se mantuvo dentro del alcance el 100 % de las veces.
  • OpenAI publica fragmentos de la cadena de razonamiento del modelo (traducidos aquí, en el original están en inglés): «No podemos asumir que exista una API extra ni un controlador de ataques que no sea el objetivo; solo deberíamos atacar el binario o el servidor» y «No exploremos credenciales fuera del alcance».

El 99,93 % no es un decimal estadístico: es la respuesta a la pregunta de en qué parte del sistema de seguridad vive la garantía. Si el aviso forma parte del sistema de despliegue, el efecto de contención depende de la plataforma y se puede auditar ahí. Si el comportamiento depende del prompt, depende de que nadie lo olvide. La mejora, según OpenAI, refleja entrenamiento específico para permanecer dentro del alcance autorizado, respetar las restricciones y contar los resultados con exactitud.

Y conviene no confundir dos mecanismos que aquí aparecen juntos. El rechazo es el modelo diciendo que no hace la tarea. El alcance es el modelo haciendo la tarea y respetando las reglas de juego. En la tabla de RemoteExploitBench se ven los dos: un modelo que rechaza el 100 % de los trabajos ofensivos y otro que completa el 95 %. Solo el segundo sirve en un equipo de seguridad, y solo el segundo necesita una arquitectura de autorización por debajo.

Las defensas que rodean al modelo

Alrededor del modelo, OpenAI ha apilado controles que describe en la misma publicación:

  • Monitorización específica de desalineación. Se comprueba si las acciones del modelo se corresponden con la autorización del usuario, sin estorbar el desarrollo legítimo de exploits.
  • Monitorización dirigida sobre amenazas emergentes. Durante la divulgación coordinada de vulnerabilidades críticas de PHP, montaron vigilancia específica sobre los intentos de desarrollar exploits contra servidores PHP vivos, conservando el apoyo a los que se limitan a parchear.
  • Private Safety Processing. Comprobaciones automáticas sobre las interacciones relacionadas; los clientes de API con retención cero de datos deben usar este mecanismo, que revisa registros cifrados conservados durante 30 días sin exponerlos al personal de OpenAI.
  • Control de acceso por direcciones IP. El acceso a la API de Daybreak Red exige por defecto una lista de direcciones IP permitidas, restringida a redes aprobadas, y se vigilan las credenciales por si han sido comprometidas.
  • Aislamiento y supervisión. Siguen recomendándose el sandboxing, la revisión de acciones y la supervisión humana en los flujos de riesgo alto, y se han añadido bloqueos de asistencia de riesgo alto sobre sistemas críticos.
  • Acceso. Al principio, vía API y Codex, para un grupo seleccionado de clientes aprobados de Daybreak Red, con apertura progresiva; GPT-5.6 Cyber queda disponible para todos los clientes de Daybreak Red y se amplía el acceso alfa de Daybreak Blue con GPT-6 Astra.

Y aquí aparece una doctrina incómoda: tasa de bloqueo más alta no siempre es mejor. OpenAI razona que muchas de las técnicas que un modelo usaría para atacar son exactamente las técnicas que el trabajo de seguridad legítimo necesita, así que mide las tasas de bloqueo junto con el apoyo a la investigación y al parcheo, en lugar de perseguir un bloqueo del cien por cien. Para calibrarlo trabajó con Dragos, que evaluó modelos permisivos de Daybreak Red en un laboratorio controlado de tecnología operacional, desde el descubrimiento de red y la enumeración de activos hasta la exfiltración de datos sensibles y las acciones no autorizadas sobre dispositivos.

Es un cambio de fondo: cuando la capacidad ofensiva la llevan agentes, el objetivo de seguridad ya no puede ser bloquear todo lo peligroso, tiene que ser autorizar con precisión. De ahí que exista un grupo nuevo, Daybreak Red for Critical Infrastructure, para los equipos de infraestructura crítica que necesitan pruebas autorizadas sobre sistemas reales conservando las salvaguardas, y una convocatoria de mil millones de dólares, Daybreak for Frontline Defenders, que subsidia el acceso a equipos con recursos limitados y a proveedores de servicios esenciales.

El mismo día, 6 de noviembre, OpenAI anunció una alianza con Hacktron para buscar vulnerabilidades en los sistemas de la propia compañía, con acceso a los modelos frontera a través de Daybreak Red, después de subir las recompensas del programa de errores y de preparar un sprint de seguridad con los investigadores de Cathedral. La empresa se está aplicando a sí misma la herramienta que publica.

La lección más transferible: verifica el camino, no solo el resultado

Tres conclusiones del trabajo con el kernel se transfieren a cualquier equipo que despliegue herramientas autónomas de seguridad:

  • Verifica la ruta, no solo el resultado. El episodio del 0-day equivocado, 20 de 200 casos, es el argumento más claro posible a favor de las comprobaciones independientes. Si tu agente informa de que obtuvo root, comprueba que lo obtuvo por la vulnerabilidad que se le asignó y no por otra que tenía al lado.
  • Vuelve a auditar cuando cambian las capacidades. La campaña de julio con GPT-5.6 Sol encontró y explotó 166 escaladas de privilegios distintas por 513.690 dólares en créditos; la campaña de mediados de octubre con el modelo nuevo encontró 948 por 1.213.430. Mismo arnés, mismo kernel, más de cinco veces los hallazgos por unas 2,4 veces el coste. Código auditado hace medio año con un modelo anterior no está auditado.
  • Los modelos más fuertes necesitan menos andamiaje. Con GPT-5.5 Cyber, darle al agente 103 técnicas de explotación en un formato amigable elevó la tasa de éxito del 76,2 % al 88,9 %. Con GPT-5.6 Cyber el modelo ya elegía y aplicaba las técnicas por su cuenta, y volver a añadir esa capa mejoró el resultado solo 1,5 puntos. El andamiaje es deuda técnica que caduca.

La economía de encontrar un fallo

Los costes son la cifra más trasladable para quien dirige un equipo de seguridad:

  • Exploit exitoso, de media: 359 dólares en créditos de API. Intento fallido: 3.922 dólares, en 69 casos. Un candidato a escalada de privilegios costó alrededor del doble que uno de fuga de información (558 frente a 271).
  • El descubrimiento fue la etapa cara (316.549 dólares) y la explotación la más cara en total (775.929). La validación costó 73.330 y el cribado inicial 44.194.
  • En una prueba contra kernelCTF, el pipeline obtuvo 21 escaladas de privilegios y 25 pruebas de fuga de información en 112 horas por unos 32.936 dólares. Ese programa había aceptado 26 vulnerabilidades confirmadas de día cero en 2026, así que la recompensa hipotética rondaría 1,5 millones de dólares: unas 45 veces el coste.
  • Aplicando las recompensas históricas de Pwn2Own y TyphoonPWN (20.000 y 70.000 dólares por escalada de privilegios) a los 948 exploits, la valoración ficticia se sitúa entre 18,9 y 66,3 millones de dólares, entre 16 y 55 veces el coste del pipeline.

Pero hay un reloj detrás. El escaneo se hizo sobre la rama principal del kernel a mediados de octubre; diez días después de que terminaran el escaneo autónomo y el análisis manual, 61 escaladas de privilegios ya estaban parcheadas aguas arriba, 43 tenían parches en fase de preparación y 299 se estaban reportando y discutiendo públicamente. La ventana entre que el modelo encuentra el fallo y el mantenedor lo corrige se mide en días, no en meses. La propia OpenAI formula el problema como una ventana limitada para usar modelos frontera en la defensa antes de que esas capacidades estén al alcance de cualquiera.

Qué hacer en tu equipo

  • Trata la salida del agente como una pista, no como un hallazgo: verifica la ruta, el reproductor y el impacto antes de informar a nadie.
  • Presupuesta las reauditorías: una auditoría hecha con el modelo del mes pasado ya está obsoleta.
  • No construyas un andamiaje elaborado alrededor de un modelo potente; construye alrededor de él la verificación.
  • Mantén a la persona humana en el punto donde se decide la autorización, no en el punto donde se redacta el texto.
  • Si mantienes software abierto, prepárate para un caudal de informes: prioriza por si el fallo cruza una frontera de privilegios y por si es reproducible.
  • Y plantéate la pregunta ya no es si una IA encontrará tu fallo, sino si lo encontrarás tú antes que el modelo con menos escrúpulos.

No es lo mismo que otros casos que ya contamos

  • En el post del 29 de octubre sobre Claude y el CVE-2026-98432, el protagonista era una cadena de explotación concreta y el mecanismo interno del kernel. Aquí el protagonista es un modelo especializado trabajando a escala industrial y, sobre todo, el diseño de la capa de autorización que lo rodea.
  • En el post del 7 de octubre sobre el Project Glasswing de Anthropic, el ángulo era el volumen de hallazgos y el programa de acceso por niveles. Aquí el ángulo es la alineación de un modelo ofensivo y su contención.
  • En el post del 25 de octubre sobre la infraestructura de entrenamiento de OpenAI, el protagonista era la fuga del aislamiento. Aquí el modelo trabaja deliberadamente dentro de un alcance estrecho.

Fuentes

Read more