Mil posibles vías de acceso con privilegios de root menos

La investigación de seguridad que antes requería una investigación independiente y prolongada para cada hallazgo puede llevarse cada vez más a cabo como un proceso sistemático. Este documento explora uno de nuestros esfuerzos en esta área.

Cada vez es más fácil escalar el descubrimiento de vulnerabilidades, pero la priorización y la validación siguen siendo cuellos de botella operativos. Creamos un prototipo para buscar fallas de seguridad en el kernel de Linux en un entorno de investigación controlado. Nuestro prototipo identificó y analizó 2308 posibles hallazgos en el kernel de Linux, reprodujo dinámicamente 1724 vulnerabilidades y generó 948 exploits de escalada local de privilegios (LPE) que podrían permitir que un usuario local sin privilegios obtenga acceso con privilegios de root.

Usamos esta evidencia para priorizar las vulnerabilidades que debíamos reportar y desarrollamos posibles parches para que los revisaran las personas encargadas del mantenimiento. Siguiendo las pautas de la comunidad del kernel de Linux, empezamos por las vulnerabilidades críticas y estamos colaborando con nuestros socios de Patch the Planet en otros informes y parches.

En junio, como parte de nuestra iniciativa Patch the Planet, compartimos que GPT‑5.5 Cyber había identificado vulnerabilidades del kernel de Linux y desarrollado 24 exploits de escalada local de privilegios para validarlas y reportarlas. Ampliamos ese trabajo a un proceso impulsado por un próximo modelo de ciberseguridad, que abarca el descubrimiento 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 reportaron las vulnerabilidades encontradas junto con parches.

El kernel de Linux sustenta los dispositivos Android, la infraestructura en la nube, las supercomputadoras y otros sistemas que usan 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, redes, sistemas de archivos y controladores de dispositivos. Elegimos Linux para estudiar con qué eficacia 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 etapa inicial de detección de vulnerabilidades generó miles de posibles hallazgos, demasiados para que los investigadores de seguridad pudieran revisarlos y clasificarlos manualmente. El principal desafío operativo de nuestro proceso de detección de vulnerabilidades no era encontrarlas, sino determinar qué hallazgos podían reproducirse, qué límites de seguridad vulneraban y cuáles requerían atención prioritaria por parte de los responsables del mantenimiento.

La misión del equipo de ciberseguridad de OpenAI es ayudar a proteger el software del que depende el mundo. Informamos los costos de API de cada etapa para ayudar a quienes investigan a evaluar los recursos necesarios para reproducir y ampliar este trabajo. Estos costos reflejan los modelos, las configuraciones de destino y el flujo de trabajo utilizados en esta evaluación. Nuestro objetivo general es ayudar a quienes defienden el software a encontrar y corregir vulnerabilidades, reducir las oportunidades disponibles para quienes atacan y aumentar el costo de explotar el software.

Por último, cabe señalar que en esta investigación nos centramos en la metodología y en medir la capacidad del modelo, no en el costo. Esperamos que un desarrollo adecuado del arnés de ejecución pueda reducir significativamente el costo en cada etapa; por lo tanto, los costos que reportamos representan más bien un límite superior.

Nuestro prototipo de investigación de vulnerabilidades es un proceso de cinco etapas que usa como núcleo un modelo de ciberseguridad que llegará próximamente:

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

• Validación dinámica: los agentes intentan reproducir cada candidato en un entorno aislado y conservar la evidencia de ejecución. Este paso genera las vulnerabilidades reproducidas y validadas.

• Evaluación de la explotabilidad: los agentes prueban 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: el equipo de investigación de seguridad revisa el exploit, el parche y la gravedad propuesta antes de informar a las personas responsables del mantenimiento.

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

No todas las líneas de código del kernel de Linux son relevantes para la seguridad. Nuestro proceso utilizó un equipo de agentes Scout para identificar los componentes de mayor prioridad para las auditorías, que luego se enviaron a los agentes Analyst para analizar posibles vulnerabilidades.

Los agentes Scout revisan cada carpeta y archivo y determinan qué objetivos auditar según su accesibilidad (si los usuarios con pocos privilegios pueden acceder a ellos) y su relevancia para la seguridad.

En esta etapa se identificaron 5034 objetivos de auditoría, unos 2,8 millones de líneas de código, lo que representa aproximadamente el 7 % de toda la base de código del kernel de Linux. Esto redujo significativamente el costo de la auditoría de seguridad en comparación con un análisis de toda la base de código. Este paso costó USD 3426 en créditos de API.

A continuación, los agentes Analyst analizaron cada objetivo de auditoría y generaron posibles hallazgos mediante un flujo de trabajo similar al del complemento de seguridad Codex⁠(se abre en una nueva ventana). A grandes rasgos, los agentes Analyst leyeron el código del objetivo de auditoría asignado para entender cómo funciona, identificar su modelo de amenazas y buscar vulnerabilidades.

En 12 horas, los agentes Analyst generaron 2308 hallazgos preliminares tras eliminar los duplicados. Esta etapa costó USD 316 549 en créditos de API.

Un hallazgo potencial no es lo mismo que una vulnerabilidad validada. A esta escala, investigar manualmente cada informe no es práctico para nuestro equipo de investigación.

Por lo tanto, nos centramos en validar los hallazgos que a) eran accesibles para alguien con pocos privilegios, b) no requerían capacidades especiales y c) producían evidencia medible de corrupción de memoria.

Para cada candidato, un agente de triaje generó una prueba de concepto y la ejecutó en una máquina virtual aislada con un kernel de Linux que usaba Kernel Address Sanitizer (KASAN). El agente observó tanto la salida del programa como la consola del sistema y luego perfeccionó la prueba de concepto de forma iterativa hasta reproducir el comportamiento informado o agotar las posibles formas de desencadenarlo.

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

La mayoría de los hallazgos restantes requerían privilegios elevados o no pudieron reproducirse dentro del tiempo disponible debido a condiciones de carrera difícil de explorar, condiciones específicas de activación (p. ej., una falla de asignación requerida en una línea específica) o una validación que llevaba mucho tiempo (p. ej., el desbordamiento del contador de referencias). Solo el 3,1 % reflejó un análisis incorrecto del modelo, en el que la vulnerabilidad reportada suponía una condición imposible.

La fase de validación costó un total de USD 73 330 en créditos de API. Observamos que, en nuestro proceso de validación, que debía generar una prueba de concepto para confirmar si un candidato era una vulnerabilidad real, este proceso resultaba más costoso que hacer una recomendación basada únicamente en el análisis estático. Además, los costos de intentar validar un verdadero positivo y un falso positivo eran similares. Por eso, eliminar los falsos positivos en una etapa anterior del proceso lo hace mucho más eficiente en términos de costos.

La validación confirma que una vulnerabilidad es real, pero no qué tan urgente es atenderla. Por ejemplo, una vulnerabilidad que podría permitir una escalada local de privilegios merece mayor prioridad que una que solo podría causar una denegación de servicio local. Con 1724 vulnerabilidades validadas, la siguiente tarea fue identificar los hallazgos con el mayor impacto potencial en la seguridad.

Un agente de evaluación inicial revisó estáticamente cada informe, registro de fallas y fragmento de código fuente pertinente. Fue deliberadamente permisivo para evitar descartar hallazgos potencialmente graves, pero filtró los casos sin una vía de explotación plausible. Esto redujo los resultados a 313 candidatos a filtraciones de información y 1238 candidatos de escalada local de privilegios.

Los agentes de desarrollo de exploits (ExploitDev) probaron entonces esos candidatos en máquinas virtuales aisladas, configuradas con las protecciones habilitadas por una distribución estándar de Linux, incluidas la prevención de ejecución en modo supervisor (SMEP), la prevención de acceso en modo supervisor (SMAP), la aleatorización del diseño del espacio de direcciones del kernel (KASLR) y HARDENED_USERCOPY. Esto ayudó a evitar evaluaciones poco realistas que dependieran de que las protecciones estuvieran deshabilitadas.

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

Analizamos variantes y desarrollamos 948 parches distintos para las vulnerabilidades responsables de esos exploits. Usamos esa cifra para determinar el número total de LPE únicos. El desarrollo de exploits exitosos cuesta un promedio de USD 359 en créditos. Esto hace que sea relativamente económico para los equipos de defensa comprobar si las vulnerabilidades encontradas son explotables.

El agente inicial de evaluación de vulnerabilidades costó USD 44 194 en créditos de API. La etapa de explotación costó USD 775 929 en créditos de API en total, USD 84 929 para procesar candidatos de filtración de información y USD 691 000 para candidatos de escalada local de privilegios.

En promedio, procesar un candidato a escalada de privilegios locales (USD 558) costó aproximadamente el doble que procesar un candidato a filtración de información (USD 271). Esto se debe a que las PoC de filtración de información se reutilizaron de la etapa de validación y necesitaron menos modificaciones para poder usarse en un exploit. En cambio, desarrollar un exploit a partir de un candidato a escalada de privilegios locales requirió muchos pasos adicionales, como planificar la estrategia de explotación, identificar objetos vulnerables que se pudieran usar y eludir las mitigaciones, entre otros. También observamos que los intentos de explotación fallidos (USD 3922 en 69 casos) costaron mucho más que los exitosos (USD 360 en 1169 casos). Esto se debió a algunas vulnerabilidades difíciles de explotar (p. ej., las condiciones de carrera). Definir una condición razonable para abandonar el intento, como detenerlo después de una hora sin avances, habría reducido significativamente el costo del desarrollo de exploits.

Para cada vulnerabilidad validada, el sistema también genera un parche. Le proporcionamos al modelo el código fuente pertinente y lo guiamos con un prompt sobre buenas prácticas para escribir parches, como realizar comprobaciones estáticas del parche, seguir las prácticas de desarrollo de software usadas en el código cercano y realizar un análisis de variantes para asegurarnos de que el parche esté completo.

Siguiendo la sugerencia de la comunidad del kernel de Linux, ya enviamos cientos de informes y parches para vulnerabilidades críticas y trabajamos con nuestros socios de Patch the Planet para enviar gradualmente parches para las demás. Este trabajo forma parte de nuestro compromiso más amplio de Daybreak para apoyar proyectos de código abierto.

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

Durante esta investigación, observamos que el equipo de mantenimiento de Linux actuaba con rapidez para corregir vulnerabilidades y proteger a quienes usan el sistema. El análisis se realizó en la versión más reciente del kernel de Linux a mediados de octubre de 2026. Cuando finalizaron el análisis autónomo y la revisión manual, después de 10 días, ya se habían incorporado correcciones para 61 vulnerabilidades de escalada local de privilegios (LPE) al proyecto original, otras 43 contaban con parches preliminares y 299 se habían reportado y estaban siendo objeto de debate público.

Agradecemos mucho a las personas que mantienen Linux y que han trabajado con urgencia para corregir los problemas identificados, así como a la comunidad de seguridad en general, que también aporta sus hallazgos. Esta respuesta colectiva es lo que se necesita para proteger el software del mundo. La rápida divulgación de vulnerabilidades y la aplicación de parches también destacan la importancia de que los usuarios y las empresas mantengan el software actualizado.

Conclusión: la clasificación automatizada debe tener en cuenta el ciclo rápido de aplicación de parches. Volver a validar los hallazgos con el código más reciente, incluido el código nuevo integrado después del análisis original, ayuda a evitar informes duplicados u obsoletos. Así, la atención se centra en las vulnerabilidades sin resolver y quienes mantienen el código cuentan con evidencia sobre la que pueden actuar, sin añadir una carga innecesaria de revisión.

Durante el desarrollo del proceso, a finales de julio de 2026, GPT‑5.6 Sol encontró y explotó 166 vulnerabilidades únicas de LPE, con un costo total de USD 513 690 en créditos de API durante todo el proceso.

En el segundo análisis, a mediados de octubre de 2026, el modelo de ciberseguridad más nuevo encontró y explotó 948 vulnerabilidades de LPE únicas, con un costo total de USD 1 213 430 en créditos de API. Para ambas campañas, analizamos la rama master más reciente del kernel de Linux disponible en ese momento.

Conclusión: vuelve a analizar el código que ya se haya auditado a medida que mejoren las capacidades de los modelos. Un modelo más avanzado puede detectar vulnerabilidades que los modelos anteriores pasaron por alto, incluso si se utiliza el mismo arnés de ejecución.

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

De las 10 técnicas, dos son nuevos objetos elásticos persistentes que el modelo utilizó para rociar objetos dentro de la caché del kernel objetivo; dos son nuevas técnicas de preparación de páginas para mejorar la confiabilidad de la explotación; cinco son nuevas técnicas basadas únicamente en datos para obtener una escalada de privilegios directamente o mediante una escritura arbitraria; la otra técnica implica una confusión de tipos arbitraria. Por motivos de seguridad, omitimos compartir los detalles técnicos completos de estas nuevas técnicas de explotación en esta publicación.

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

Una parte importante de la misión de nuestro equipo es medir el costo de encontrar y explotar vulnerabilidades, y usar esa evidencia para orientar la inversión en defensa. Nuestro objetivo es ayudar a quienes defienden el software a corregir las vulnerabilidades antes de que los atacantes puedan aprovecharlas, y hacer que explotarlo resulte demasiado costoso para ellos. Medir los costos de explotación nos ayuda a evaluar cómo cambia ese desafío a medida que mejoran las capacidades de los modelos. En esta sección, comparamos el costo de una ejecución de nuestro proceso con las recompensas de los programas de recompensas por errores para las vulnerabilidades identificadas.

Las máquinas virtuales objetivo de nuestro experimento ejecutaban un sistema operativo de escritorio estándar, no un sistema objetivo debilitado, bajo el mismo modelo de amenazas que se utiliza en competencias de ciberseguridad (p. ej., Pwn2Own⁠(se abre en una nueva ventana), TyphoonPWN⁠(se abre en una nueva ventana)). Históricamente, Pwn2Own y TyphoonPWN ofrecían recompensas por encontrar errores de USD 20 000 y USD 70 000, respectivamente, por exploits de escalada local de privilegios en el kernel de Linux. Aplicar esos montos históricos de recompensa a los 948 exploits da como resultado una valoración hipotética de entre USD 18,9 millones y USD 66,3 millones, aproximadamente entre 16 y 55 veces el costo de nuestro proceso.

También probamos nuestro proceso con el programa de recompensas por vulnerabilidades kernelCTF⁠(se abre en una nueva ventana) de Google, cuyo objetivo es un kernel de Linux reforzado con superficies de ataque reducidas. Ejecutamos el proceso en la última versión del kernel de Linux (incompatible con la mitigación SLAB_VIRTUAL de kernelCTF, por lo que la eliminamos de la configuración) en el entorno de kernelCTF y obtuvimos 25 pruebas de concepto de filtración de información y 21 exploits de LPE. A modo de comparación, al momento de redactar este texto, kernelCTF aceptó 26 exploits de LPE de día cero confirmados en 2026. La campaña duró 112 horas en total, con un costo aproximado de USD 32 936 en créditos de API; el descubrimiento de vulnerabilidades representó el 83,7 % del costo de API. Si el programa aceptara las 21 vulnerabilidades, la recompensa rondaría los USD 1,5 millones, aproximadamente 45 veces el costo.

Conclusión: según los montos de los pagos disponibles públicamente, al momento de realizar esta investigación, nuestro proceso de investigación de vulnerabilidades generaba ganancias netas con los modelos actuales especializados en ciberseguridad. Los equipos de defensa deben analizar su software de manera proactiva para que explotar sus vulnerabilidades resulte demasiado costoso para los atacantes.

Durante la evaluación de explotabilidad, los agentes ExploitDev recibieron un informe de vulnerabilidad y la tarea de crear un exploit totalmente funcional. Nuestro proceso marcaba una vulnerabilidad como explotada si se lograba obtener una shell con privilegios de root. En una ejecución inicial, la etapa de explotación reportó 200 exploits exitosos de escalada local de privilegios. Sin embargo, tras una revisión humana, descubrimos que 20 de ellos habían obtenido privilegios de root a través de una vulnerabilidad de día 0 distinta de la asignada. Esto sugiere que incluso la explotación exitosa por parte de los agentes requiere una validación adecuada.

Después, hicimos más estrictas las restricciones de la tarea y agregamos una verificación independiente para confirmar que cada exploit final usara la vulnerabilidad asignada.

Conclusión: en la investigación autónoma de seguridad, es necesario verificar no solo el resultado en sí, sino también el proceso seguido para obtenerlo. El aislamiento, la supervisión y las verificaciones independientes son controles esenciales.

Al inicio de esta investigación, evaluamos la decisión de diseño de crear una orquestación pesada alrededor del agente para mejorar sus capacidades en ciberseguridad. El resultado indicó que los modelos más potentes requieren menos orquestación y menos asistencia directa. Y la mejora marginal no justifica el costo de mantenimiento. Como resultado, decidimos eliminar la orquestación pesada.

El experimento comparó GPT‑5.5 Cyber y GPT‑5.6 Cyber. Observamos que GPT‑5.5 Cyber no identificaba de forma consistente cuándo ni cómo aplicar las técnicas existentes de explotación del kernel de Linux. Luego reunimos 103 técnicas en un formato fácil de procesar para el modelo, las pusimos a disposición en el entorno del agente y le indicamos al agente que las usara. En 63 candidatos de explotación, esto aumentó la tasa de éxito del 76,2 % al 88,9 %.

Al repetir esto con GPT‑5.6 Cyber, el modelo pudo encontrar, seleccionar y aplicar por su cuenta técnicas pertinentes con mayor eficacia. Eliminamos la orquestación de técnicas y habilidades, y este flujo de trabajo de GPT‑5.6 Cyber, con poca orquestación, superó al flujo de trabajo de GPT‑5.5 Cyber, con una estructura mucho más elaborada. Al volver a añadir la capa adicional de técnicas para GPT‑5.6 Cyber, la mejora fue de apenas 1,5 puntos porcentuales.

Conclusión: vuelve a evaluar la orquestación y el arnés de ejecución a medida que evolucionen las capacidades de los modelos base. La infraestructura de apoyo que mejora considerablemente el rendimiento de una generación de modelos puede aportar poco valor a un modelo más avanzado, por lo que es importante evaluar si sus beneficios justifican el esfuerzo de mantenimiento.

Al principio, cuando se le pedía directamente que generara parches candidatos, el modelo creaba parches funcionalmente correctos que mitigaban el exploit de prueba de concepto, pero a veces introducía otros problemas: más código del necesario, posibles desventajas de rendimiento, desviaciones de las convenciones de programación o falta de revisión del código relacionado para detectar variantes de la misma vulnerabilidad, lo que daba lugar a parches incompletos.

Las instrucciones adicionales y las iteraciones en el proceso de generación de parches mejoraron la calidad de estos, lo que sugiere que, con un enfoque adecuado, es posible que los parches de seguridad generados por IA sean correctos, mínimos y coherentes con las convenciones de código existentes. Esta es un área de investigación activa y creemos que, con los modelos futuros, este proceso será 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 aplicar parches, pero las habilidades para aplicar parches y los arneses de ejecución pueden requerir iteraciones para garantizar que los parches cumplan de manera confiable tanto los requisitos funcionales como los no funcionales. Además, recomendamos usar modelos para realizar revisiones adversariales de los parches generados por humanoa y por IA, ya que pueden identificar problemas como que el parche se pueda evadir, que omita otras vías de ataque o variantes, entre otros.

Durante nuestra ejecución de 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 de QEMU TCG. Al agente Analyst se le asignó analizar el código de entrada de las llamadas al sistema y, al escribir programas para experimentar con transiciones de privilegios, detectó un fallo inesperado del kernel. Analizó el fallo y rastreó su origen hasta 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 los exploits manualmente y confirmamos que ya se había corregido en el proyecto original de QEMU, pero no en la compilación de la versión utilizada durante el experimento.

Conclusión: los modelos de vanguardia con capacidades cibernéticas pueden encontrar vulnerabilidades en la infraestructura de pruebas. Recomendamos probar cada parte de la infraestructura antes de realizar investigaciones ofensivas sobre vulnerabilidades. Ya realizamos pruebas proactivas de nuestra infraestructura, y divulgamos y corregimos muchas vulnerabilidades en Kata, Moby/Docker, gVisor y otros proyectos.

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

A través de Patch the Planet, una iniciativa de Daybreak, buscamos ampliar esta investigación a más proyectos de software críticos y desarrollar mecanismos confiables de aplicación automatizada de parches junto con quienes mantienen el software y los socios de seguridad. Queremos reducir gradualmente las oportunidades disponibles para los atacantes y aumentar el costo de encontrar y explotar vulnerabilidades, hasta que la recompensa esperada ya no justifique 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 vulnerar. Seguiremos trabajando para construir una Internet segura sobre la que cualquier persona pueda crear con entusiasmo.