Mil caminos menos al acceso root

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

Cada vez es más fácil ampliar la escala del 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 dentro de 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 produjo 948 exploits de escalada local de privilegios (LPE) que podrían permitir a un usuario local sin privilegios obtener acceso root.

Usamos esta evidencia para priorizar las vulnerabilidades que debíamos informar y desarrollamos propuestas de parches para que los responsables de mantenimiento las revisaran. Siguiendo las recomendaciones de la comunidad del kernel de Linux, comenzamos por las vulnerabilidades críticas y estamos trabajando con los socios de Patch the Planet en más 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 e informarlas. Ampliamos ese trabajo hasta convertirlo en un flujo de trabajo impulsado por un próximo modelo de ciberseguridad, que abarca el descubrimiento de vulnerabilidades, la validación dinámica, la evaluación de explotabilidad y la generación de parches. Una vez finalizado, investigadores humanos revisaron los resultados e informaron las vulnerabilidades encontradas junto con sus parches.

El kernel de Linux es la base de dispositivos Android, infraestructura en la nube, 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 expone 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 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 descubrimiento de vulnerabilidades produjo miles de posibles hallazgos, demasiados para que los investigadores de seguridad los revisaran y clasificaran manualmente. El desafío operativo de nuestro flujo de descubrimiento de vulnerabilidades no era descubrirlas, sino determinar qué hallazgos podían reproducirse, qué límite de seguridad traspasaban y cuáles merecían atención prioritaria 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. Informamos los costos de API de cada etapa para ayudar a los investigadores a evaluar los recursos necesarios para reproducir y ampliar este trabajo. Estos costos reflejan los modelos, las configuraciones de los objetivos y el flujo de trabajo usados 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 elevando el costo de explotar el software.

Por último, ten en cuenta que esta investigación se centró en la metodología y en medir la capacidad de los modelos, no en el costo. Esperamos que un trabajo de ingeniería suficiente sobre el arnés de ejecución pueda reducir considerablemente el costo de cada etapa; por lo tanto, los costos que informamos representan más bien un límite superior.

Nuestro prototipo de investigación de vulnerabilidades es un flujo de trabajo de cinco etapas que tiene como núcleo un próximo modelo de ciberseguridad:

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

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

• Evaluación de 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: los investigadores de seguridad revisan el exploit, el parche y la gravedad propuesta antes de informar a los responsables de mantenimiento.

Al final del flujo de trabajo, el sistema reúne un análisis de 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 principal.

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

Los agentes exploradores leen cada carpeta y archivo, y determinan qué objetivos auditar según su accesibilidad para usuarios con pocos privilegios 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 equivale aproximadamente al 7 % de toda la base de código del kernel de Linux. Esto redujo significativamente el costo de la auditoría de seguridad frente a un análisis de toda la base de código. Este paso costó $3426 en créditos de API.

Luego, los agentes analistas analizaron cada objetivo de auditoría y produjeron posibles hallazgos mediante un flujo de trabajo similar al del complemento Codex Security⁠(se abre en una nueva ventana). En términos generales, los agentes analistas leen 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 analistas produjeron 2308 posibles hallazgos, tras eliminar los duplicados. Esta etapa costó $316 549 en créditos de API.

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

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

Para cada posible hallazgo, un agente de clasificación 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 refinó la prueba de concepto de forma iterativa hasta reproducir el comportamiento informado o agotar las posibles formas de activarlo.

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 producir falsos positivos, por lo que nos impresionaron la precisión de los agentes analistas y la eficacia de los agentes de clasificación 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 dentro del tiempo asignado debido a condiciones de carrera difíciles, condiciones de activación específicas (por ejemplo, un fallo de asignación necesario en una línea concreta) o validaciones lentas (por ejemplo, el desbordamiento de un contador de referencias). Solo el 3,1 % correspondía a análisis incorrectos del modelo, en los que la vulnerabilidad informada suponía una condición imposible.

La etapa de validación costó $73 330 en créditos de API en total. En nuestro flujo de validación, que debía generar una prueba de concepto para confirmar si un posible hallazgo era una vulnerabilidad real, observamos que este proceso era más costoso que hacer una recomendación basada solo en el análisis estático. Además, los costos de intentar validar un verdadero positivo y un falso positivo eran similares. Por lo tanto, eliminar los falsos positivos en las primeras etapas del flujo de trabajo mejora considerablemente la eficiencia de costos del proceso.

La validación establece que una vulnerabilidad es real, pero no con qué urgencia debe atenderse. Una vulnerabilidad que podría permitir una escalada local de privilegios, por ejemplo, merece mayor prioridad que una que solo podría causar 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 realizó una revisión estática de cada informe, registro de fallo y fragmento de código fuente relevante. Sus criterios eran deliberadamente permisivos para evitar descartar hallazgos potencialmente graves, al tiempo que filtraba 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.

Luego, los agentes de desarrollo de exploits (ExploitDev) probaron esos casos en máquinas virtuales aisladas configuradas con las protecciones habilitadas en 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 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 que permitían esos exploits. Usamos esa cifra para determinar el número total de vulnerabilidades de LPE únicas. Desarrollar los exploits exitosos costó un promedio de $359 en créditos. Esto hace que probar la explotabilidad de las vulnerabilidades encontradas sea relativamente económico para los defensores.

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

En promedio, procesar una posible escalada local de privilegios ($558) costó aproximadamente el doble que procesar una posible filtración de información ($271). Esto se debe a que se reutilizaron las pruebas de concepto de filtración de información de la etapa de validación y se necesitaron menos modificaciones para poder usarlas en un exploit. En cambio, desarrollar un exploit a partir de una posible vulnerabilidad de LPE requirió muchos pasos adicionales, como planificar la estrategia de explotación, identificar objetos vulnerables que usar, eludir mitigaciones y más. También observamos que los intentos fallidos de explotación ($3922 para 69 casos) costaron mucho más que los exitosos ($360 para 1169 casos). Esto se debió a unas pocas vulnerabilidades difíciles de explotar (por ejemplo, condiciones de carrera). Definir una condición de abandono razonable, como detener el intento tras una hora sin avances, habría reducido significativamente el costo de ExploitDev.

El sistema también genera un parche para cada vulnerabilidad validada. Proporcionamos al modelo el código fuente relevante y le indicamos 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 asegurar 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 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 aprendizajes, 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 principal, 43 tenían parches en preparación y 299 se estaban informando y debatiendo públicamente.

Agradecemos profundamente a los responsables de mantenimiento de Linux que han trabajado con urgencia para corregir los problemas identificados, así como a toda la comunidad de seguridad que también aporta sus hallazgos. Esta respuesta colectiva es lo que se necesita para proteger el software del mundo. El rápido ritmo de divulgación de vulnerabilidades y aplicación de parches también pone de relieve lo fundamental que es para usuarios y empresas mantener el software actualizado.

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

Mientras desarrollábamos el flujo de trabajo, a finales de julio de 2026, GPT‑5.6 Sol encontró y explotó 166 vulnerabilidades de LPE únicas, con un costo total de $513 690 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 únicas, con un costo total de $1 213 430 en créditos de API. En ambas campañas, analizamos la versión más reciente de la rama master del kernel de Linux disponible en ese momento.

Conclusión clave: 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 los modelos anteriores pasaron por alto, incluso con el mismo arnés de ejecución para 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 usaron 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 usó 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 obtener una escalada de privilegios directamente o mediante una escritura arbitraria; y la restante implica una confusión arbitraria de tipos. Por motivos de seguridad, no compartimos en esta publicación todos los detalles técnicos de estas nuevas técnicas de explotación.

Conclusión clave: los modelos de vanguardia no se limitan a reconocer patrones conocidos de código vulnerable ni a usar técnicas de explotación conocidas; demuestran creatividad y 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 los defensores a corregir vulnerabilidades antes de que los atacantes puedan usarlas y hacer que explotar el software les resulte prohibitivamente costoso. 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 ejecutar nuestro flujo de trabajo con las recompensas que ofrecerían los programas de recompensas por errores para las vulnerabilidades identificadas.

Las máquinas virtuales objetivo de nuestro experimento ejecutaban un sistema operativo de escritorio con su configuración estándar, sin debilitarlo, bajo el mismo modelo de amenazas que usan las competencias de ciberseguridad (por ejemplo, Pwn2Own⁠(se abre en una nueva ventana) y TyphoonPWN⁠(se abre en una nueva ventana)). Históricamente, Pwn2Own y TyphoonPWN ofrecían recompensas de $20 000 y $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 una valoración hipotética de $18,9 millones a $66,3 millones, aproximadamente de 16 a 55 veces el costo de nuestro flujo de trabajo.

También probamos nuestro flujo de trabajo 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 flujo de trabajo sobre la última versión 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. Esa versión era incompatible con la mitigación SLAB_VIRTUAL de kernelCTF, por lo que la quitamos de la configuración. Como referencia, al momento de redactar este documento, kernelCTF había aceptado 26 exploits de LPE de día cero confirmados en 2026. La campaña completa duró 112 horas y costó aproximadamente $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, se obtendría una recompensa de unos $1,5 millones, aproximadamente 45 veces el costo.

Conclusión clave: según los montos públicos de las recompensas, nuestro flujo de investigación de vulnerabilidades con los modelos actuales con capacidades de ciberseguridad habría generado ganancias netas al momento de esta investigación. Los defensores deben analizar su software de forma proactiva para que explotarlo resulte prohibitivamente 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 completamente funcional. Nuestro flujo de trabajo marcaba una vulnerabilidad como explotada si se lograba obtener una shell con privilegios root. Durante una de las primeras ejecuciones, la etapa de explotación informó 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 mediante una vulnerabilidad de día cero distinta de la asignada. Esto sugiere que incluso la explotación exitosa por parte de los agentes requiere una validación adecuada.

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

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

Al comienzo de esta investigación, evaluamos la decisión de diseño de crear o no una orquestación compleja en torno al agente para mejorar su capacidad de ciberseguridad. Nuestro resultado sugirió que los modelos más capaces requieren una orquestación más ligera y menos orientación. Además, la mejora marginal no justifica el costo de mantenimiento. Por eso, 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 usar para el modelo, las pusimos a disposición del agente en su entorno y le indicamos que las usara. En 63 posibles casos de explotación, esto aumentó la tasa de éxito del 76,2 % al 88,9 %.

Al repetirlo con GPT‑5.6 Cyber, el modelo pudo encontrar, seleccionar y aplicar mejor las técnicas pertinentes por su cuenta. Eliminamos la orquestación de técnicas y habilidades, y este flujo de trabajo de GPT‑5.6 Cyber con orquestación ligera superó al de GPT‑5.5 Cyber, que contaba con una estructura de apoyo más compleja. Volver a añadir la capa adicional de técnicas para GPT‑5.6 Cyber solo aportó una mejora marginal de 1,5 puntos porcentuales.

Conclusión clave: reevalúa tu orquestación y tu arnés de ejecución a medida que cambien las capacidades del modelo base. Una estructura de apoyo que mejora sustancialmente una generación de modelos puede aportar poco valor a un modelo más capaz, por lo que debe evaluarse si compensa su costo de mantenimiento.

Al principio, cuando se le pedía directamente que generara propuestas de parches, el modelo creaba parches funcionalmente correctos que mitigaban la prueba de concepto, pero a veces introducían otros problemas: incluían más código del necesario, podían perjudicar el rendimiento o se desviaban de las convenciones de código. En otros casos, no examinaba 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 sobre el proceso de generación mejoraron la calidad de los parches. Esto sugiere que, con una gestión adecuada, los parches de seguridad generados por IA pueden ser 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 futuros modelos 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 luego se corrigieron antes de incorporarlos.

Conclusión clave: los modelos pueden acelerar el proceso de aplicación de parches, pero las habilidades y los arneses de ejecución para esta tarea pueden requerir iteraciones para garantizar que los parches cumplan de forma confiable tanto los requisitos funcionales como los no funcionales. Además, recomendamos usar modelos para revisar, desde la perspectiva de un adversario, los parches generados por humanos y por IA. Esto puede identificar problemas como la posibilidad de eludir el parche o la omisión de otras vías o variantes de ataque, entre otros.

En 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 analista se le asignó analizar el 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. Evaluó el fallo y rastreó el origen del problema 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 manualmente los exploits y confirmamos que ya se había corregido en el proyecto principal de QEMU, pero no en la compilación publicada que se usó durante el experimento.

Conclusión clave: los modelos de vanguardia con capacidades de ciberseguridad pueden encontrar vulnerabilidades en la infraestructura de pruebas. Recomendamos probar cada parte de la infraestructura antes de realizar investigaciones ofensivas de vulnerabilidades. Hemos probado nuestra infraestructura de forma proactiva, y divulgado y corregido numerosas vulnerabilidades en Kata, Moby/Docker, gVisor y otros proyectos.

Nuestro objetivo es convertir la creciente capacidad 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 usarse para buscar vulnerabilidades de manera 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, buscamos extender esta investigación a más proyectos de software críticos y desarrollar un proceso automatizado y confiable de aplicación de parches junto con responsables de mantenimiento y socios de seguridad. Queremos reducir de forma sostenida las oportunidades de los atacantes y elevar el costo de encontrar y explotar vulnerabilidades, hasta que el beneficio esperado 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 donde cualquier persona pueda disfrutar de crear.