948 exploits de escalada local capaces de llevar a root: ese es el resultado que OpenAI atribuye a una ejecución de 30 horas de su nueva canalización automatizada sobre Linux. La compañía afirma que el sistema reprodujo 1.724 vulnerabilidades, generó además pruebas de concepto para 291 fallos de filtración de información y preparó parches para los problemas identificados. El coste total fue de 1.213.430 dólares en créditos de API.
La cifra describe tanto el salto de capacidad que OpenAI quiere mostrar como un problema de seguridad más inmediato: descubrir fallos y producir exploits puede acelerarse, pero el valor defensivo depende de que los hallazgos se validen, lleguen a los mantenedores y se conviertan en actualizaciones instaladas. La empresa dice que investigadores humanos revisaron los resultados y que ya ha enviado informes y correcciones. Los números, sin embargo, son los de OpenAI; no hay una verificación independiente de los 948 casos.
De 2.308 candidatos a 948 exploits
La prueba se realizó a mediados de octubre con un modelo de ciberseguridad todavía no publicado. OpenAI describe un proceso de cinco etapas: localizar código relevante, reproducir los hallazgos en un entorno aislado, evaluar si podían explotarse, proponer parches y someter los resultados a revisión humana.
Según los datos publicados por la compañía y detallados por IT之家, los agentes seleccionaron 5.034 objetivos de auditoría, que abarcaban alrededor de 2,8 millones de líneas de código, cerca del 7% del kernel. De ese análisis salieron 2.308 candidatos. La fase de validación reprodujo 1.724, aproximadamente tres cuartas partes, en máquinas virtuales aisladas.
La evaluación posterior encontró 1.169 casos en los que los agentes lograron una escalada local, pero el recuento final quedó en 948 vulnerabilidades distintas, tras el análisis de variantes y el trabajo de parches. La diferencia importa: no se trata de 948 avisos iniciales ni de 948 candidatos sin probar, sino del número final que OpenAI presenta como vulnerabilidades diferentes con exploits funcionales.
La compañía dice que los exploits se probaron en una distribución Linux de escritorio con protecciones habituales activadas, entre ellas SMEP, SMAP, KASLR y HARDENED_USERCOPY. No publicó el nombre de la distribución ni la versión del kernel utilizada. También afirma que los agentes generaron pruebas de concepto para 291 vulnerabilidades de filtración de información.
La secuencia convierte el análisis de código en una cadena de validación, explotación, reparación y revisión:
flowchart TD A["Seleccionar código"] --> B["Analizar candidatos"] B --> C["Validar en entorno aislado"] C --> D["Evaluar explotación"] D --> E["Proponer parches"] E --> F["Revisión humana"] F --> G["Informar a mantenedores"]
El coste baja por fallo, pero sigue siendo alto
Los 1.213.430 dólares equivalen, según OpenAI, a unos 1.279 dólares por exploit. IT之家 atribuye 775.900 dólares a la fase de desarrollo de exploits, la parte más cara del proceso. La cifra no debe leerse como un precio estable por vulnerabilidad: OpenAI reconoce que corresponde al modelo, la configuración y el flujo de trabajo de esa prueba, y que no representa el mínimo posible tras optimizar la coordinación de agentes.
La comparación con una ejecución anterior ofrece una medida del cambio, aunque no un experimento controlado. En julio, OpenAI utilizó GPT-5.6 Sol y comunicó 166 vulnerabilidades de escalada local por 513.690 dólares. En octubre, con un modelo distinto y una canalización revisada, el resultado fue más de cinco veces superior, pese a que entre ambas pruebas el kernel había recibido alrededor de tres meses de refuerzo de seguridad.
El coste por resultado sugiere que el análisis automatizado puede aumentar el volumen de investigación sin que cada hallazgo requiera el mismo esfuerzo manual que una auditoría tradicional. Pero el gasto total de esta ejecución, superior al millón de dólares, también pone una cautela: no es una herramienta gratuita ni una operación que cualquier equipo pueda replicar con facilidad. Además, una parte significativa del trabajo no termina al generar un exploit. Hace falta descartar duplicados, revisar si el fallo es real, entender el impacto y elaborar una corrección que no introduzca otros problemas.
Una capacidad ofensiva que también sirve para corregir
OpenAI sostiene que su sistema no se limitó a encontrar fallos: también propuso parches. IT之家 explica que las primeras versiones podían ser redundantes, afectar potencialmente al rendimiento, apartarse de las convenciones del proyecto o dejar sin cubrir variantes del mismo fallo. La compañía afirma que añadió restricciones y repitió el proceso para mejorar la calidad; algunos parches generados, añade, ayudaron a detectar problemas en soluciones escritas previamente por expertos humanos.
La revisión humana es, por tanto, una parte del mecanismo y no un trámite que pueda darse por resuelto con la salida del modelo. Los investigadores deben evaluar el exploit, la corrección propuesta y la gravedad antes de informar a los mantenedores. Según los datos difundidos por OpenAI, durante los diez días de análisis y revisión, 61 vulnerabilidades ya habían sido corregidas en el kernel upstream, 43 contaban con parches en preparación y otras 299 estaban en discusión pública o en proceso de notificación.
La cifra de correcciones confirma que hay trabajo en marcha, pero no equivale a que todas las vulnerabilidades estén reparadas o que los sistemas que usan Linux estén protegidos. Un parche upstream debe integrarse en distribuciones y productos, y después instalarse en los equipos afectados. OpenAI dice que priorizó los fallos graves siguiendo las indicaciones de la comunidad del kernel y que enviará los informes restantes con socios de Patch the Planet.
La propia empresa resume el riesgo de los sistemas atrasados con una advertencia contundente:
“For the near and medium term, having access to a low-privileged account on an operating system that isn't up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor.”
— OpenAI
El salto no elimina las dudas sobre la medición
OpenAI afirma que los agentes emplearon al menos diez técnicas de explotación de Linux que eran nuevas para el equipo y para especialistas externos consultados. Entre ellas, The Hacker News enumera métodos para manipular objetos persistentes del kernel, mejorar la fiabilidad de exploits y obtener escalada mediante técnicas de solo datos. La compañía no publicó los detalles completos por motivos de seguridad.
Hay también un antecedente que obliga a leer las cifras con cuidado. ArtificialWatch informa de que, en una ejecución inicial, 20 de 200 éxitos comunicados habían alcanzado el objetivo mediante una vulnerabilidad distinta de la asignada. OpenAI dice que corrigió ese problema incorporando una comprobación. Esa revisión mejora el proceso, pero no constituye una auditoría externa de los resultados finales.
La prueba adicional en el entorno reforzado de kernelCTF produjo 21 exploits de escalada local y 25 pruebas de concepto de filtración de información, con un coste aproximado de 32.936 dólares y una duración de 112 horas, según IT之家. Times of AI compara los 21 resultados con los 26 exploits de escalada zero-day que kernelCTF habría aceptado en todo 2026. El contexto es distinto del análisis sobre una distribución de escritorio: ese entorno tiene una superficie de ataque menor y, según ArtificialWatch, se desactivó una mitigación que la última versión del kernel no admitía.
Por eso, comparar directamente los resultados entre pruebas puede exagerar lo que el modelo hace por sí solo. Cambian el objetivo, el entorno, las defensas, la versión del modelo y la organización de los agentes. Tampoco se conoce públicamente qué modelo se utilizó en octubre: OpenAI lo identifica solo como un modelo de ciberseguridad próximo a publicarse.
Qué cambia para mantenedores y empresas
Para quienes mantienen software, el efecto práctico no es que deban aceptar automáticamente parches generados por IA, sino que el volumen de informes potenciales puede crecer con rapidez. Si los hallazgos llegan más deprisa, la clasificación, la reproducción y la coordinación de correcciones pueden convertirse en el cuello de botella. OpenAI pide acompasar la detección automatizada con la generación de parches; el estado de los informes publicados muestra que esa tarea implica colaborar con los responsables del kernel y seguir sus procedimientos.
Las organizaciones que despliegan Linux afrontan la otra mitad del problema: reducir el tiempo entre la disponibilidad de una corrección y su instalación. El Centro Nacional de Ciberseguridad del Reino Unido, citado por The Hacker News, advirtió que las herramientas defensivas de IA pueden acortar el periodo entre la aparición de un fallo zero-day y su conversión en un fallo conocido, pero que los sistemas seguirán expuestos si la tecnología no se configura correctamente y no se extienden las correcciones. También pidió adaptar los procesos internos de actualización y pruebas al nuevo ritmo de descubrimiento.
La advertencia tiene una dimensión ofensiva. Las mismas capacidades que ayudan a los defensores pueden facilitar a otros la búsqueda y preparación de exploits. The Hacker News recoge además que Google Threat Intelligence Group observó un aumento de 5.045 vulnerabilidades divulgadas en enero de 2026 a 10.740 en agosto, y que las clasificadas como de alto riesgo pasaron de 131 a 350 en ese periodo. Esas cifras describen divulgaciones, no prueban que la IA sea su causa; el propio artículo vincula el cambio con una tendencia más amplia de aceleración en el hallazgo de vulnerabilidades.
OpenAI sostiene que, a medio plazo, los modelos podrían descubrir fallos complejos y ayudar a explotar vulnerabilidades ya divulgadas. Para las empresas, el resultado de octubre convierte una cuenta local de pocos privilegios en un riesgo más serio cuando el sistema está atrasado en parches. La pregunta inmediata no es cuándo se publicará el modelo, dato que OpenAI no ha anunciado, sino cuántos de los informes pendientes llegarán a convertirse en correcciones instalables.
Fuentes: The Hacker News, IT之家, Times of AI, ArtificialWatch
