948 vías desde una cuenta común hasta el control total
OpenAI afirma que un sistema automatizado de investigación encontró 948 vulnerabilidades distintas del kernel de Linux que podrían permitir a alguien con una cuenta de usuario común tomar el control total de una computadora. La campaña costó 1.213.430 dólares en créditos de API de IA y generó parches candidatos para que los revisaran personas, según la divulgación de los resultados de la investigación de la empresa, publicada el 4 de noviembre de 2026.
Contenido
- 948 vías desde una cuenta común hasta el control total
- Cómo los agentes redujeron millones de líneas de código
- Qué demostraron los exploits funcionales
- Cómo se comparó la campaña de octubre con trabajos anteriores
- Por qué obtener acceso root no bastaba para validar un hallazgo
- Qué se obtuvo por 1,2 millones de dólares y cómo lo valoró OpenAI
- Diez técnicas supuestamente nuevas, con detalles reservados
- La brecha entre una corrección aceptada en el proyecto y una máquina protegida
- Un ciclo de detección más rápido va más allá de las computadoras de escritorio con Linux
- Puntos clave
Los resultados detallados en el informe de investigación de OpenAI explican cómo se llegó a la cifra principal: los agentes generaron 1.169 exploits funcionales de escalada local de privilegios; después, agruparon los hallazgos relacionados mediante un análisis de variantes y desarrollaron 948 parches distintos. OpenAI usa esta última cifra como recuento de vulnerabilidades únicas.
Una falla de escalada local de privilegios permite que una persona o un programa que ya se ejecuta en una máquina obtenga poderes normalmente reservados al administrador, conocido como root. El kernel de Linux es el software central que gestiona la memoria, el hardware y los permisos de acceso. Romper esa barrera puede convertir un acceso limitado en el control del sistema.
OpenAI probó los exploits en una distribución de Linux de uso común, cuyo nombre no reveló, con las protecciones de seguridad habituales activadas. La empresa describió la IA que impulsaba el proceso como un próximo modelo cibernético, sin dar una fecha de lanzamiento ni identificar la distribución. Las cifras de hallazgos y costos, así como las afirmaciones sobre nuevas técnicas de ataque, son resultados publicados por la propia OpenAI.
El desafío inmediato es lograr que las correcciones lleguen a las computadoras que la gente usa en la práctica. Durante la investigación, colaboradores de Linux ya estaban corrigiendo o debatiendo cientos de hallazgos coincidentes. Los investigadores humanos aún debían comprobar si cada exploit apuntaba a la falla que decía atacar y si el parche propuesto abordaba su causa.
Cómo los agentes redujeron millones de líneas de código
OpenAI comenzó seleccionando partes de Linux accesibles para usuarios comunes y relevantes para la seguridad. Los agentes de exploración identificaron 5.034 objetivos de auditoría que abarcaban unos 2,8 millones de líneas de código, cerca del 7% de un código base del kernel con más de 40 millones de líneas.
Después, los agentes de análisis examinaron esos objetivos, estudiaron cómo funcionaba el código y dónde podría un atacante atravesar una barrera de seguridad. En 12 horas, generaron 2.308 hallazgos candidatos, una vez eliminados los duplicados. Seleccionar los objetivos costó 3.426 dólares en créditos de API; analizarlos costó 316.549 dólares.
El proceso completo tuvo cinco etapas: detección de vulnerabilidades, validación dinámica, evaluación de la posibilidad de explotación, generación de parches y revisión humana. Cada etapa respondió a una pregunta distinta: pasó del código sospechoso a un problema de seguridad demostrado y, luego, a una reparación propuesta.
Durante la validación, los agentes intentaron reproducir cada caso candidato en una máquina virtual aislada mediante Kernel Address Sanitizer, una herramienta que detecta ciertos errores de memoria. Observaron la salida de los programas y los registros del sistema, y ajustaron sus programas de prueba hasta activar el problema o agotar los intentos asignados.
En 30 horas, el sistema reprodujo 1.724 vulnerabilidades, cerca del 74,7% de los casos candidatos. OpenAI dijo que muchos de los hallazgos restantes requerían privilegios superiores o dependían de condiciones difíciles de activar dentro del tiempo disponible. Atribuyó el 3,1% de los hallazgos candidatos a análisis incorrectos relacionados con una condición imposible. Las 30 horas correspondieron a esta etapa de validación, mientras que el análisis y la revisión manual posteriores se extendieron durante 10 días.
Qué demostraron los exploits funcionales
El siguiente paso de OpenAI fue determinar cuáles de los errores reproducidos podían exponer información o permitir obtener acceso root. Un agente de selección redujo los hallazgos a 313 casos candidatos de filtración de información y 1.238 posibles casos de escalada de privilegios.
Los agentes de desarrollo de exploits generaron 291 pruebas de concepto de filtración de información y 1.169 exploits funcionales de escalada de privilegios. Una prueba de concepto es un programa de prueba que demuestra que se puede activar una vulnerabilidad. Un exploit va más allá y aprovecha la falla para lograr una consecuencia de seguridad, como obtener privilegios de administrador.
Las máquinas de prueba mantuvieron activas protecciones como la aleatorización de direcciones, las restricciones al acceso del kernel a la memoria de usuario y las comprobaciones al copiar datos. La aleatorización de direcciones dificulta que un atacante prediga ubicaciones de memoria útiles. Mantener activas estas protecciones hizo que las pruebas se acercaran más a una instalación normal de escritorio.
OpenAI también probó una versión adaptada del entorno kernelCTF de Google, que tiene una superficie de ataque más pequeña y protecciones adicionales. Esa campaña produjo 25 pruebas de concepto de filtración de información y 21 exploits de escalada de privilegios durante 112 horas, con un costo de API de unos 32.936 dólares. La adaptación omitió la mitigación SLAB_VIRTUAL porque era incompatible con la versión más reciente del kernel usada en la prueba.
OpenAI informó que encontró una vulnerabilidad en QEMU TCG, parte de la infraestructura de virtualización utilizada en sus pruebas de kernelCTF. El hallazgo hizo que el propio entorno de investigación quedara incluido en la revisión de seguridad.
Cómo se comparó la campaña de octubre con trabajos anteriores
La investigación de OpenAI sobre Linux se amplió a través de varios experimentos en 2026. La empresa vinculó este trabajo con Patch the Planet, su iniciativa para ayudar a los responsables del mantenimiento a detectar y corregir vulnerabilidades en software de uso extendido.
- Junio de 2026: OpenAI divulgó 24 exploits de escalada de privilegios en Linux desarrollados con GPT-5.5 Cyber.
- Finales de julio de 2026: una campaña con GPT-5.6 Sol encontró y explotó 166 vulnerabilidades únicas de escalada de privilegios, con un costo de API de 513.690 dólares.
- Mitad de octubre de 2026: el modelo cibernético más reciente generó exploits para 948 vulnerabilidades distintas de escalada de privilegios, junto con parches candidatos, a un costo de 1.213.430 dólares.
- 4 de noviembre de 2026: OpenAI publicó su descripción del proceso y de los resultados.
La campaña de octubre encontró cerca de 5,7 veces más vulnerabilidades únicas de escalada de privilegios que la de julio, con un gasto unas 2,4 veces mayor. A partir de esas cifras, el gasto de API por hallazgo único bajó de unos 3.095 a 1.280 dólares.
Ambas campañas examinaron la rama principal más reciente del kernel de Linux disponible en ese momento. OpenAI dijo que el modelo de octubre encontró muchas más vulnerabilidades pese a que habían transcurrido tres meses adicionales de correcciones y refuerzos de seguridad del kernel. La empresa sostuvo que el software importante debería volver a analizarse a medida que los modelos aumenten su capacidad.
Por qué obtener acceso root no bastaba para validar un hallazgo
OpenAI encontró un problema básico en un experimento inicial: 20 de 200 exploits exitosos obtuvieron acceso root mediante una vulnerabilidad distinta de la asignada al agente. El ataque funcionó, pero la explicación sobre qué falla había aprovechado era incorrecta.
Eso era importante para aplicar los parches. Los investigadores deben vincular el resultado observado con la causa correcta para que los responsables del mantenimiento puedan reparar el código responsable. OpenAI añadió comprobaciones independientes tras detectar las atribuciones erróneas.
Yash Kadakia, fundador y director de tecnología de Security Brigade, explicó por qué las empresas necesitan resultados reproducibles y explicaciones precisas:
«Lograr un resultado y explicar correctamente cómo se logró son dos cosas distintas», dijo.
Los paquetes finales de investigación de OpenAI incluían un análisis de la causa, un programa de prueba mínimo que provocaba un fallo, un parche candidato y un exploit completo. Investigadores humanos de seguridad revisaron el exploit, la corrección y la gravedad propuesta antes de informar de los hallazgos a los responsables del mantenimiento.
El desarrollo de parches también requirió iteraciones. Algunas correcciones iniciales de la IA introdujeron cambios innecesarios o compromisos de rendimiento, o dejaron sin resolver variantes relacionadas de una vulnerabilidad. Probar distintas variantes de un ataque ayudó a los investigadores a evaluar si la reparación cubría el problema más amplio.
Qué se obtuvo por 1,2 millones de dólares y cómo lo valoró OpenAI
OpenAI informó que el costo total de la campaña fue de 1.213.430 dólares, unos 1.279 dólares por hallazgo único de escalada de privilegios. Estas cifras describen el gasto de API de los modelos y el proceso, no un cálculo completo de la mano de obra de investigación y los gastos operativos.
La evaluación de la posibilidad de explotación absorbió la mayor parte del gasto. La selección costó 44.194 dólares, mientras que el desarrollo de exploits costó 775.929 dólares, incluidos 691.000 dólares para casos candidatos de escalada de privilegios y 84.929 dólares para casos candidatos de filtración de información.
Los casos difíciles podían resultar especialmente costosos. OpenAI informó un gasto promedio de unos 3.922 dólares por cada uno de 69 intentos fallidos de escalada de privilegios, frente a unos 360 dólares por cada exploit exitoso. Algunos casos particularmente difíciles implicaban condiciones de carrera, en las que el éxito depende de que ciertos eventos ocurran en un orden o momento precisos.
OpenAI comparó los 948 hallazgos con las recompensas históricas de competiciones: 20.000 dólares en Pwn2Own y 70.000 dólares en TyphoonPWN por exploits de escalada de privilegios en el kernel de Linux. Al aplicar esas cantidades, obtuvo un valor hipotético de entre 18,9 y 66,3 millones de dólares, aproximadamente entre 16 y 55 veces el costo de API de la campaña.
La empresa también estimó que sus 21 exploits de kernelCTF podrían generar unos 1,5 millones de dólares si el programa los aceptara. Ambas comparaciones son estimaciones condicionales de recompensas; los premios reales dependen de las reglas del programa y de la aceptación. OpenAI dijo que su trabajo se centró en medir la capacidad, no en minimizar los costos, y que una mejor ingeniería del proceso podría reducir el gasto.
Diez técnicas supuestamente nuevas, con detalles reservados
OpenAI examinó una muestra de 166 exploits y dijo que identificó al menos 10 técnicas de explotación nuevas para sus investigadores y para especialistas externos en explotación del kernel consultados durante el trabajo. La empresa no divulgó instrucciones detalladas por razones de seguridad.
Las técnicas incluían dos nuevos objetos usados para colocar datos controlados por el atacante en la memoria del kernel, dos formas de organizar la memoria para mejorar la fiabilidad, cinco métodos para obtener privilegios mediante cambios en los datos y uno que implicaba confusión de tipos arbitraria. La confusión de tipos ocurre cuando el software trata un objeto como si fuera de otro tipo, lo que puede permitir el acceso a datos u operaciones incorrectos.
OpenAI presentó estos resultados como prueba de que los agentes podían desarrollar enfoques que fueran más allá de los patrones de explotación conocidos. La afirmación se basa en la revisión de la muestra por parte de la empresa y en las consultas a especialistas externos.
La consecuencia práctica para los defensores es que las reparaciones deben probarse frente a variantes de ataque relacionadas, además de la primera demostración funcional. OpenAI dijo que las iteraciones guiadas por especialistas podrían ayudar a producir parches que funcionen correctamente, se integren con el código circundante y resistan ataques variantes.
La brecha entre una corrección aceptada en el proyecto y una máquina protegida
Los responsables del mantenimiento de Linux ya estaban actuando mientras se desarrollaba la campaña de OpenAI. Al final de los 10 días que abarcaron el análisis y la revisión manual, 61 hallazgos de escalada de privilegios ya tenían parches aceptados en el proyecto principal, 43 contaban con parches en fase de preparación y 299 se estaban comunicando y debatiendo públicamente.
Una corrección aceptada en el proyecto principal es un cambio incorporado al proyecto central. Un parche en fase de preparación todavía está en revisión o integración. Después, las distribuciones de Linux deben entregar actualizaciones adecuadas a sus clientes, quienes deben instalarlas y activar el kernel corregido.
OpenAI dijo que había enviado cientos de informes y parches, comenzando por las vulnerabilidades críticas de acuerdo con las pautas de la comunidad del kernel. No proporcionó un desglose completo del estado de corrección de los 948 hallazgos.
Sakshi Grover, directora de investigación de IDC, señaló que el principal motivo de preocupación es el período antes de que las correcciones lleguen a los sistemas en funcionamiento:
«El riesgo no reside tanto en los 948 hallazgos como en la duración del período entre su detección y la llegada de las correcciones a los sistemas de producción», dijo.
Grover recomendó dar prioridad a los equipos anfitriones compartidos por varios clientes, los sistemas automatizados de compilación de software, los servidores de acceso compartido, las plataformas de contenedores y las máquinas de los desarrolladores. También instó a las organizaciones a solicitar a las distribuciones de Linux plazos para incorporar las correcciones a las versiones con soporte.
Thomas Di Giacomo, director de tecnología y productos de SUSE, dijo que la empresa utiliza herramientas de IA similares y colabora con las comunidades responsables de los proyectos principales en la divulgación y aplicación de parches. Describió el enfoque de SUSE como una combinación de varias capas de protección y entornos de ejecución de aplicaciones reforzados.
Un ciclo de detección más rápido va más allá de las computadoras de escritorio con Linux
Las cifras del Grupo de Inteligencia sobre Amenazas de Google sitúan en 10.740 las vulnerabilidades divulgadas en agosto de 2026, frente a 5.045 en enero. Las divulgaciones clasificadas como de alto riesgo aumentaron de 131 a 350 en el mismo período, un incremento de alrededor del 167%.
El Centro Nacional de Ciberseguridad del Reino Unido abordó la detección asistida por IA en una evaluación publicada el 3 de noviembre. El organismo dijo:
«La disponibilidad generalizada de herramientas cibernéticas basadas en IA casi con certeza ha provocado un aumento significativo en la detección de vulnerabilidades de día cero», afirmó.
Una vulnerabilidad de día cero es una falla ante la que los defensores no han tenido oportunidad de preparar una corrección con antelación. El NCSC dijo que las herramientas defensivas de IA habían acelerado la aplicación de parches, pero advirtió que muchos sistemas seguían expuestos cuando esas herramientas no estaban bien configuradas ni ampliamente implementadas. Las organizaciones tendrían que adaptar sus procesos de aplicación de parches y pruebas al ritmo más rápido.
El amplio alcance de Linux hace que este problema operativo afecte a muchos sectores. El kernel es compatible con dispositivos Android, infraestructura en la nube y supercomputadoras. La infraestructura de cadena de bloques también está expuesta: cerca de dos tercios de los nodos de Ethereum usan Linux, según cifras de ethernodes.org citadas en la cobertura de los hallazgos.
Mudit Gupta, director de tecnología de Polygon Labs, sostuvo que la infraestructura distribuida ofrece resiliencia:
«La descentralización aporta diversidad en la infraestructura y redundancia, lo que hace que las criptomonedas sean mucho más resilientes ante errores como este que el software tradicional».
El investigador de seguridad Caducus también sostuvo que la infraestructura de criptomonedas se había vuelto más resiliente tras exponerse repetidamente a ataques. Para quienes operan sistemas individuales, la tarea concreta sigue siendo mantener las máquinas actualizadas y limitar el daño que puede causar una cuenta comprometida.
OpenAI recomendó defensas por capas, incluidas zonas de pruebas y sistemas de aislamiento como Firecracker y gVisor. Su advertencia fue directa: un atacante con recursos suficientes y una cuenta común en un sistema operativo al que no se hayan aplicado parches disponibles podría convertir ese acceso en control root. Detectar errores más rápido solo ayuda si las correcciones resultantes llegan rápidamente a esos sistemas.
Puntos clave
- OpenAI informó que identificó 948 vulnerabilidades distintas de escalada de privilegios en Linux tras analizar 1.169 exploits funcionales y generar parches candidatos.
- La campaña de octubre costó 1.213.430 dólares en créditos de API. En la etapa de validación se reprodujeron 1.724 vulnerabilidades candidatas en 30 horas.
- Las pruebas se realizaron en una distribución normal de Linux con las protecciones estándar activadas; no se identificaron el modelo ni la distribución.
- La revisión humana seguía siendo necesaria para verificar la causa de cada exploit y evaluar las correcciones propuestas.
- Los responsables del mantenimiento ya habían aplicado parches a 61 hallazgos en el proyecto principal; otros 43 tenían parches en fase de preparación y 299 se debatían públicamente al terminar el análisis.
- La prioridad defensiva inmediata es distribuir e instalar las correcciones, sobre todo en sistemas compartidos donde un acceso común podría convertirse en control de administrador.
