Mil vías menos para obtener acceso root

La investigación de seguridad, que antes requería un estudio independiente y prolongado de cada hallazgo, puede llevarse a cabo cada vez más como un proceso sistemático. Este documento explora uno de nuestros trabajos en este ámbito.

Cada vez es más fácil ampliar la escala de la detección de vulnerabilidades, pero su priorización y validación siguen siendo cuellos de botella operativos. Creamos un prototipo para buscar fallos de seguridad en el kernel de Linux dentro de un entorno de investigación controlado. Nuestro prototipo identificó y analizó 2308 posibles vulnerabilidades del kernel de Linux, reprodujo de forma dinámica 1724 vulnerabilidades y produjo 948 exploits de escalada local de privilegios (LPE) que podrían permitir a un usuario local sin privilegios obtener acceso root.

Utilizamos estas pruebas para priorizar qué vulnerabilidades comunicar y desarrollamos propuestas de parches para que las revisaran los responsables de mantenimiento. Siguiendo las indicaciones de la comunidad del kernel de Linux, empezamos por las vulnerabilidades críticas y estamos trabajando con los socios de Patch the Planet en nuevos informes y parches.

En junio, como parte de nuestra iniciativa Patch the Planet, compartimos que GPT‑5.5 Cyber había identificado vulnerabilidades en el kernel de Linux y desarrollado 24 exploits de escalada local de privilegios para validarlas y comunicarlas. Ampliamos ese trabajo hasta convertirlo en un flujo de trabajo, impulsado por un próximo modelo de ciberseguridad, que abarca la detección de vulnerabilidades, la validación dinámica, la evaluación de la explotabilidad y la generación de parches. Al finalizar, investigadores humanos revisaron los resultados y comunicaron las vulnerabilidades detectadas junto con sus parches.

El kernel de Linux es la base de dispositivos Android, infraestructura en la nube, superordenadores y otros sistemas que utilizan miles de millones de personas. Con más de 40 millones de líneas de código, el kernel presenta una amplia superficie de ataque a través de llamadas al sistema, funciones de red, sistemas de archivos y controladores de dispositivos. Elegimos Linux para estudiar la eficacia con la que los modelos de vanguardia podían encontrar vulnerabilidades y demostrar su impacto en la seguridad en una base de código de esta escala e importancia.

La fase inicial de detección de vulnerabilidades produjo miles de posibles hallazgos, demasiados para que los investigadores de seguridad los revisaran y clasificaran manualmente. El reto operativo de nuestro flujo de detección de vulnerabilidades no era encontrarlas, sino determinar qué hallazgos podían reproducirse, qué límite de seguridad traspasaban y cuáles requerían la atención más urgente de los responsables de mantenimiento.

La misión del equipo de ciberseguridad de OpenAI es ayudar a proteger el software del que depende el mundo. Publicamos los costes de API de cada fase para ayudar a los investigadores a evaluar los recursos necesarios para reproducir y ampliar este trabajo. Estos costes reflejan los modelos, las configuraciones de los objetivos y el flujo de trabajo utilizados en esta evaluación. Nuestro objetivo más amplio es ayudar a los defensores a encontrar y corregir vulnerabilidades, reduciendo las oportunidades de los atacantes y aumentando el coste que les supone explotar el software.

Por último, ten en cuenta que esta investigación se centró en la metodología y en medir las capacidades de los modelos, no en el coste. Esperamos que un trabajo suficiente de ingeniería del arnés pueda reducir considerablemente el coste de cada fase; por tanto, los costes que publicamos deben entenderse más bien como un límite superior.

Nuestro prototipo de investigación de vulnerabilidades es un flujo de trabajo de cinco fases cuyo núcleo es un próximo modelo de ciberseguridad:

• Detección de vulnerabilidades: los agentes identifican las partes del código relevantes para la seguridad y las analizan en busca de posibles vulnerabilidades.

• Validación dinámica: los agentes intentan reproducir cada posible vulnerabilidad en un entorno aislado y conservan las pruebas obtenidas durante la ejecución. Este paso produce las vulnerabilidades reproducidas y validadas.

• Evaluación de la explotabilidad: los agentes comprueban si las vulnerabilidades validadas podrían permitir la divulgación de información o la escalada local de privilegios.

• Generación de parches: los agentes generan parches que corrigen cada vulnerabilidad identificada.

• Revisión humana: los investigadores de seguridad revisan el exploit, el parche y la gravedad propuesta antes de enviar el informe a los responsables de mantenimiento.

Al final del flujo de trabajo, el sistema reúne un análisis de la causa raíz, una prueba de concepto mínima que provoca un fallo, una propuesta de parche y un exploit completo para ayudar a los investigadores humanos a evaluar la gravedad de la vulnerabilidad e incorporar las correcciones al proyecto original.

No todas las líneas de código del kernel de Linux son relevantes para la seguridad. Nuestro flujo de trabajo utilizó un equipo de agentes exploradores para identificar objetivos de auditoría de alto valor, que después se pasaron a agentes analistas para buscar vulnerabilidades.

Los agentes exploradores examinan cada carpeta y archivo y determinan qué objetivos auditar en función de su accesibilidad para usuarios con privilegios limitados y de su relevancia para la seguridad.

En esta fase se identificaron 5034 objetivos de auditoría, unos 2,8 millones de líneas de código, lo que supone aproximadamente el 7 % de todo el código del kernel de Linux. Esto redujo considerablemente el coste de la auditoría de seguridad frente a un análisis de todo el código. Este paso costó 3426 dólares en Créditos de API.

A continuación, los agentes analistas examinaron cada objetivo de auditoría y detectaron posibles vulnerabilidades mediante un flujo de trabajo similar al del complemento Codex Security⁠(se abre en una ventana nueva). A grandes rasgos, los agentes analistas leen el código del objetivo de auditoría asignado para comprender cómo funciona, identificar su modelo de amenazas y buscar vulnerabilidades.

En 12 horas, los agentes analistas detectaron 2308 posibles vulnerabilidades, una vez eliminados los duplicados. Esta fase costó 316 549 dólares en Créditos de API.

Una posible vulnerabilidad no es lo mismo que una vulnerabilidad validada. A esta escala, investigar manualmente cada informe resulta inviable para nuestro equipo de investigación.

Por eso nos centramos en validar los hallazgos que a) fueran accesibles para un usuario con privilegios limitados, b) no requirieran capacidades especiales y c) produjeran pruebas medibles de corrupción de memoria.

Para cada posible vulnerabilidad, un agente de triaje generó una prueba de concepto y la ejecutó en una máquina virtual aislada con un kernel de Linux que incluía Kernel Address Sanitizer (KASAN). El agente observó tanto la salida del programa como la consola del sistema y fue perfeccionando la prueba de concepto hasta reproducir el comportamiento descrito o agotar las posibles formas de desencadenarlo.

En 30 horas, nuestro sistema reprodujo 1724 vulnerabilidades, aproximadamente el 74,7 % de los 2308 posibles hallazgos. La revisión estática del código por sí sola puede generar falsos positivos, por lo que nos impresionaron la precisión de los agentes analistas y la eficacia de los agentes de triaje al crear de forma autónoma pruebas de concepto funcionales para casi tres cuartas partes de los posibles hallazgos.

La mayoría de los hallazgos restantes requerían privilegios elevados o no pudieron reproducirse en el tiempo asignado debido a condiciones de carrera difíciles de provocar, condiciones de activación específicas (por ejemplo, un fallo de asignación necesario en una línea concreta) o validaciones lentas (como el desbordamiento de un contador de referencias). Solo el 3,1 % se debía a un análisis incorrecto del modelo, en el que la vulnerabilidad descrita presuponía una condición imposible.

La fase de validación costó en total 73 330 dólares en Créditos de API. En nuestro flujo de validación, que necesitaba generar una prueba de concepto para confirmar si un posible hallazgo era una vulnerabilidad real, observamos que este proceso era más caro que formular una recomendación basada solo en el análisis estático, y que intentar validar un verdadero positivo costaba aproximadamente lo mismo que intentar validar un falso positivo. Por tanto, eliminar los falsos positivos en fases más tempranas mejora considerablemente la eficiencia económica del proceso.

La validación establece que una vulnerabilidad es real, pero no la urgencia con la que debe corregirse. Por ejemplo, una vulnerabilidad que pudiera permitir una escalada local de privilegios merece mayor prioridad que otra que solo pudiera provocar una denegación de servicio local. Con 1724 vulnerabilidades validadas, la siguiente tarea era identificar los hallazgos con mayor impacto potencial en la seguridad.

Un agente de selección inicial revisó de forma estática cada informe, registro de fallos y fragmento de código fuente pertinente. Sus criterios eran deliberadamente permisivos para evitar descartar hallazgos potencialmente graves, pero filtraban los casos sin una vía de explotación plausible. Esto redujo los resultados a 313 posibles filtraciones de información y 1238 posibles escaladas locales de privilegios.

A continuación, los agentes de desarrollo de exploits (ExploitDev) probaron esas posibles vulnerabilidades en máquinas virtuales aisladas configuradas con las protecciones activadas en una distribución estándar de Linux, entre ellas la prevención de ejecución en modo supervisor (SMEP), la prevención de acceso en modo supervisor (SMAP), la aleatorización de la disposición del espacio de direcciones del kernel (KASLR) y HARDENED_USERCOPY. Esto ayudó a evitar evaluaciones poco realistas que dependieran de tener las protecciones desactivadas.

Los agentes produjeron 291 pruebas de concepto de filtración de información y 1169 exploits funcionales de escalada local de privilegios que podrían dar acceso root a usuarios locales sin privilegios.

Realizamos un análisis de variantes y desarrollamos 948 parches distintos para las vulnerabilidades en las que se basaban esos exploits. Utilizamos esa cifra para determinar el número total de vulnerabilidades de LPE distintas. Desarrollar los exploits exitosos costó una media de 359 dólares en Créditos. Esto hace que comprobar la explotabilidad de las vulnerabilidades detectadas resulte relativamente económico para los defensores.

El agente de selección inicial de vulnerabilidades costó 44 194 dólares en Créditos de API. La fase de explotación costó en total 775 929 dólares en Créditos de API: 84 929 dólares para procesar las posibles filtraciones de información y 691 000 dólares para las posibles escaladas locales de privilegios.

De media, procesar una posible escalada local de privilegios (558 dólares) costó aproximadamente el doble que procesar una posible filtración de información (271 dólares). Esto se debe a que las pruebas de concepto de filtración de información se reutilizaron de la fase de validación y requerían menos modificaciones para poder usarse en un exploit. En cambio, desarrollar un exploit a partir de una posible vulnerabilidad de LPE requería muchos pasos adicionales, como planificar la estrategia de explotación, identificar los objetos vulnerables que utilizar y eludir las mitigaciones. También observamos que los intentos de explotación fallidos (3922 dólares en 69 casos) costaban mucho más que los exitosos (360 dólares en 1169 casos). Esto se debió a unas pocas vulnerabilidades difíciles de explotar, como las condiciones de carrera. Definir un criterio razonable para abandonar, como detener el intento tras una hora sin avances, habría reducido considerablemente el coste de ExploitDev.

Para cada vulnerabilidad validada, el sistema también genera un parche. Proporcionamos al modelo el código fuente pertinente y le damos instrucciones sobre buenas prácticas para escribir parches, como realizar comprobaciones estáticas, seguir las prácticas de desarrollo utilizadas en el código circundante y analizar variantes para garantizar que el parche esté completo.

Siguiendo la recomendación de la comunidad del kernel de Linux, ya hemos enviado cientos de informes y parches para vulnerabilidades críticas y estamos trabajando con los socios de Patch the Planet para enviar gradualmente los parches restantes. Este trabajo forma parte de nuestro compromiso más amplio con el apoyo a los proyectos de código abierto a través de Daybreak.

En esta sección compartimos las lecciones aprendidas, reflexiones y análisis adicionales de esta investigación.

Durante esta investigación, observamos que los responsables de mantenimiento de Linux actuaban con rapidez para corregir vulnerabilidades y proteger a los usuarios. El análisis se realizó sobre la versión más reciente del kernel de Linux a mediados de octubre de 2026. Cuando el análisis autónomo y la revisión manual terminaron al cabo de 10 días, 61 vulnerabilidades de LPE ya se habían corregido en el proyecto original, 43 tenían parches pendientes de integración y 299 se estaban comunicando y debatiendo públicamente.

Agradecemos enormemente el trabajo urgente de los responsables de mantenimiento de Linux para corregir los problemas detectados, así como las aportaciones de toda la comunidad de seguridad. Esta respuesta colectiva es lo que hace falta para proteger el software de todo el mundo. El rápido ritmo de divulgación y corrección de vulnerabilidades también pone de relieve lo fundamental que es que los usuarios y las empresas mantengan el software actualizado.

Conclusión: el triaje automatizado debe tener en cuenta la rapidez del ciclo de parcheo. Volver a validar los hallazgos frente al código más reciente, incluido el que se haya incorporado tras el análisis original, ayuda a evitar informes duplicados u obsoletos. Así se centra la atención en las vulnerabilidades sin resolver y se proporcionan a los responsables de mantenimiento pruebas sobre las que pueden actuar, sin añadir una carga de revisión innecesaria.

A finales de julio de 2026, mientras desarrollábamos el flujo de trabajo, GPT‑5.6 Sol encontró y explotó 166 vulnerabilidades de LPE distintas, con un coste total de 513 690 dólares en Créditos de API.

En el segundo análisis, a mediados de octubre de 2026, el modelo de ciberseguridad más reciente encontró y explotó 948 vulnerabilidades de LPE distintas, con un coste total de 1 213 430 dólares en Créditos de API. En ambas campañas analizamos la versión más reciente de la rama master del kernel de Linux en ese momento.

Conclusión: vuelve a analizar el código ya auditado a medida que mejoren las capacidades de los modelos. Un modelo más capaz puede descubrir vulnerabilidades que modelos anteriores pasaron por alto, incluso utilizando el mismo arnés de investigación.

Tomamos una muestra de 166 exploits desarrollados por los agentes y analizamos las técnicas de explotación utilizadas. Hasta donde sabemos, los agentes utilizaron 10 técnicas de explotación nuevas en los exploits de la muestra. Compartimos las técnicas de explotación con expertos externos en explotación del kernel, y también eran nuevas para ellos.

De las 10 técnicas, dos consisten en nuevos objetos elásticos persistentes que el modelo utilizó para llenar de objetos la caché objetivo del kernel; dos son nuevas técnicas de preparación de páginas de memoria para mejorar la fiabilidad del exploit; cinco son nuevas técnicas que operan solo sobre datos para conseguir una escalada de privilegios directamente o mediante una escritura arbitraria; y la restante implica una confusión de tipos arbitraria. Por motivos de seguridad, no compartimos todos los detalles técnicos de estas nuevas técnicas de explotación en esta publicación.

Conclusión: los modelos de vanguardia no se limitan a reconocer patrones conocidos de código vulnerable ni a utilizar únicamente técnicas de explotación conocidas; demuestran creatividad y enfoques novedosos.

Una parte importante de la misión de nuestro equipo es medir el coste de encontrar y explotar vulnerabilidades y utilizar esos datos para orientar la inversión en defensa. Nuestro objetivo es ayudar a los defensores a corregir las vulnerabilidades antes de que los atacantes puedan aprovecharlas y lograr que el coste de explotar el software les resulte prohibitivo. Medir los costes de explotación nos ayuda a evaluar cómo cambia ese reto a medida que mejoran las capacidades de los modelos. En esta sección comparamos el coste de ejecutar nuestro flujo de trabajo con las recompensas que ofrecen los programas de detección de vulnerabilidades por los fallos identificados.

Las máquinas virtuales objetivo de nuestro experimento ejecutaban un sistema operativo de escritorio estándar, no una versión con la seguridad debilitada, bajo el mismo modelo de amenazas que se utiliza en competiciones de ciberseguridad (como Pwn2Own⁠(se abre en una ventana nueva) y TyphoonPWN⁠(se abre en una ventana nueva)). Históricamente, Pwn2Own y TyphoonPWN han ofrecido recompensas de 20 000 y 70 000 dólares, respectivamente, por exploits de escalada local de privilegios en el kernel de Linux. Aplicar esas recompensas históricas a los 948 exploits arroja una valoración hipotética de entre 18,9 y 66,3 millones de dólares, aproximadamente entre 16 y 55 veces el coste de nuestro flujo de trabajo.

También probamos nuestro flujo de trabajo en el programa de recompensas por vulnerabilidades kernelCTF⁠(se abre en una ventana nueva) de Google, cuyo objetivo es un kernel de Linux reforzado y con superficies de ataque reducidas. Ejecutamos el flujo de trabajo sobre la versión más reciente del kernel de Linux en el entorno de kernelCTF y obtuvimos 25 pruebas de concepto de filtración de información y 21 exploits de escalada local de privilegios. Como esa versión era incompatible con la mitigación SLAB_VIRTUAL de kernelCTF, la eliminamos de la configuración. Como referencia, en el momento de redactar este documento, kernelCTF había aceptado 26 exploits confirmados de LPE de día cero en 2026. La campaña completa duró 112 horas y costó unos 32 936 dólares en Créditos de API. La detección de vulnerabilidades supuso el 83,7 % del coste de API. Si el programa aceptara las 21 vulnerabilidades, la recompensa rondaría los 1,5 millones de dólares, aproximadamente 45 veces el coste.

Conclusión: tomando como referencia las recompensas públicas, nuestro flujo de investigación de vulnerabilidades, con los modelos actuales dotados de capacidades de ciberseguridad, generaba un beneficio neto en el momento de esta investigación. Los defensores deberían analizar su software de forma proactiva para que a los atacantes les resulte prohibitivo explotarlo.

Durante la evaluación de la explotabilidad, los agentes ExploitDev recibieron un informe de vulnerabilidad y la tarea de crear un exploit plenamente funcional. Nuestro flujo de trabajo marcaba una vulnerabilidad como explotada si se conseguía abrir una consola con privilegios root. En una de las primeras ejecuciones, la fase de explotación notificó 200 exploits exitosos de escalada local de privilegios. Sin embargo, tras una revisión humana, descubrimos que 20 de ellos habían obtenido privilegios root a través de una vulnerabilidad de día cero distinta de la asignada. Esto sugiere que incluso las explotaciones exitosas realizadas por agentes necesitan una validación adecuada.

Posteriormente endurecimos las restricciones de la tarea y añadimos una comprobación independiente para confirmar que cada exploit final utilizaba la vulnerabilidad asignada.

Conclusión: en la investigación autónoma de seguridad, verifica cómo se ha llegado al resultado, además del resultado en sí; el aislamiento, la supervisión y las comprobaciones independientes son controles necesarios.

Al principio de esta investigación, estudiamos si convenía diseñar una orquestación compleja en torno al agente para mejorar sus capacidades de ciberseguridad. Nuestros resultados sugirieron que los modelos más potentes requieren una orquestación más ligera y menos asistencia. Además, la mejora marginal no justifica el coste de mantenimiento. Por ello, decidimos eliminar la orquestación compleja.

El experimento comparó GPT‑5.5 Cyber y GPT‑5.6 Cyber. Observamos que GPT‑5.5 Cyber no identificaba de forma sistemática cuándo y cómo aplicar las técnicas existentes de explotación del kernel de Linux. Entonces recopilamos 103 técnicas en un formato fácil de procesar para el modelo, las pusimos a disposición del agente en su entorno y le dimos instrucciones para utilizarlas. En un conjunto de 63 posibles vulnerabilidades explotables, esto aumentó la tasa de éxito del 76,2 % al 88,9 %.

Al repetir el experimento con GPT‑5.6 Cyber, el modelo mostró una mayor capacidad para encontrar, seleccionar y aplicar por sí solo las técnicas pertinentes. Eliminamos la orquestación de técnicas y habilidades, y este flujo de trabajo de GPT‑5.6 Cyber con una orquestación ligera superó al de GPT‑5.5 Cyber, que contaba con una estructura de apoyo más compleja. Restaurar la capa adicional de técnicas en GPT‑5.6 Cyber solo aportó una mejora marginal de 1,5 puntos porcentuales.

Conclusión: reevalúa tu orquestación y tu arnés a medida que cambien las capacidades del modelo base. Una estructura de apoyo que mejora considerablemente una generación de modelos puede aportar poco valor a un modelo más potente, por lo que conviene evaluar si compensa su coste de mantenimiento.

Al principio, cuando se le pedía directamente que generara propuestas de parches, el modelo creaba parches funcionalmente correctos que neutralizaban la prueba de concepto, pero a veces introducían otros problemas: incluían más código del necesario, podían perjudicar el rendimiento, se apartaban de las convenciones de programación o no examinaban el código relacionado en busca de variantes de la misma vulnerabilidad, lo que daba lugar a parches incompletos.

Las instrucciones adicionales y las iteraciones del proceso de generación mejoraron la calidad de los parches. Esto sugiere que, con el enfoque adecuado, los parches de seguridad generados por IA pueden ser correctos, mínimos y coherentes con las convenciones del código existente. Se trata de un área de investigación activa, y creemos que los futuros modelos harán que este proceso sea más fácil y eficaz. En algunos casos, nuestro prototipo de investigación también pudo identificar problemas en parches escritos por expertos humanos, que se corrigieron antes de integrarlos.

Conclusión: los modelos pueden acelerar el proceso de parcheo, pero las habilidades y los arneses de parcheo pueden necesitar iteraciones para garantizar que los parches cumplan de forma fiable tanto los requisitos funcionales como los no funcionales. Además, recomendamos utilizar modelos para revisar desde una perspectiva adversaria los parches generados por humanos y por IA. Esta revisión puede detectar problemas como la posibilidad de eludir el parche, otras vías de ataque o variantes no cubiertas, entre otros.

En nuestra ejecución en kernelCTF, además de los 21 exploits de día cero del kernel de Linux, nuestro prototipo de investigación también encontró y explotó una vulnerabilidad en QEMU TCG. El agente analista tenía asignado el análisis del código de entrada de las llamadas al sistema y, al escribir programas para experimentar con transiciones de privilegios, se encontró con un fallo inesperado del kernel. Analizó el fallo y localizó el origen del problema en QEMU TCG, sin acceso al código fuente de QEMU, e incluyó la vulnerabilidad en el informe. Posteriormente, el agente ExploitDev desarrolló con éxito un exploit de escalada local de privilegios para esta vulnerabilidad. Descubrimos esta vulnerabilidad de QEMU al analizar manualmente los exploits y confirmamos que ya se había corregido en el proyecto original de QEMU, pero no en la compilación publicada que se utilizó durante el experimento.

Conclusión: los modelos de vanguardia con capacidades de ciberseguridad pueden encontrar vulnerabilidades en la infraestructura de pruebas. Recomendamos poner a prueba cada parte de la infraestructura antes de realizar una investigación ofensiva de vulnerabilidades. Hemos puesto a prueba nuestra infraestructura de forma proactiva y hemos comunicado y corregido muchas vulnerabilidades en Kata, Moby/Docker, gVisor y otros proyectos.

Nuestro objetivo es convertir las crecientes capacidades de los modelos en una ventaja duradera para quienes protegen Internet. Esta investigación demuestra que las crecientes capacidades de ciberseguridad de los modelos de vanguardia pueden utilizarse para buscar vulnerabilidades de forma eficaz en software complejo, como el kernel de Linux. Reforzar la seguridad de proyectos de software críticos como Linux y otros proyectos de código abierto puede proteger a muchos sistemas y usuarios que dependen de ellos.

A través de Patch the Planet, una iniciativa de Daybreak, queremos ampliar esta investigación a más proyectos de software críticos y desarrollar un sistema fiable de parcheo automatizado junto con sus responsables de mantenimiento y nuestros socios de seguridad. Queremos reducir de forma constante las oportunidades de los atacantes y aumentar el coste de encontrar y explotar vulnerabilidades, hasta que el beneficio esperado deje de justificar el ataque.

Cada generación de modelos debería ayudarnos a crear software que a la siguiente generación le resulte más difícil comprometer. Seguiremos trabajando para construir un Internet seguro en el que cualquiera pueda disfrutar creando.