948 exploits que llevan de usuario sin privilegios a root en el kernel de Linux, cada uno con su parche candidato, en una sola ejecución y por 1.213.430 $ en créditos de API. Es el balance que OpenAI publicó el 4 de noviembre de 2026 en «A thousand fewer paths to root»: un pipeline de agentes que audita el kernel, reproduce cada fallo, escribe el exploit y propone la corrección antes de que una persona lo revise.
El problema, con cifras
El objetivo era la última versión del kernel a mediados de octubre de 2026, centrada en el código que un usuario con pocos privilegios puede alcanzar. El embudo de esa ejecución deja claro cuánto ruido hay que filtrar:
| Fase | Resultado |
|---|---|
| Hallazgos candidatos analizados | 2.308 |
| Vulnerabilidades reproducidas dinámicamente | 1.724 |
| Pruebas de concepto de fuga de información | 291 |
| Exploits de escalada local (LPE) funcionales | 948 |
El coste medio sale a unos 1.279 $ por fallo distinto. OpenAI presenta la cifra total como una cota superior, porque un harness mejor afinado gastaría menos en cada fase. El modelo que lo hace posible es un modelo de ciberseguridad que OpenAI aún no ha lanzado.
Cómo está montado el pipeline
La clave no es que un modelo "encuentre bugs", sino que cada etapa entrega una prueba que la siguiente puede comprobar:
- Descubrimiento: agentes que analizan las zonas del kernel alcanzables sin privilegios y generan hallazgos candidatos.
- Validación dinámica: cada hallazgo se convierte en una prueba de concepto que se ejecuta en una máquina virtual hasta que el fallo se reproduce. Lo que no se reproduce, se descarta.
- Explotabilidad: los candidatos más prometedores pasan a agentes que intentan llegar a root en máquinas con un sistema operativo de escritorio estándar.
- Parche: una última fase escribe un parche candidato y hace análisis de variantes, de modo que un solo parche puede cerrar varios exploits.
- Revisión humana: investigadores revisan exploit, parche y severidad propuesta antes de enviar nada a los mantenedores.
Por eso el 948 cuenta parches, no exploits. Uno de los autores lo explicó en Hacker News: el número bruto de exploits es mayor, pero agruparon por el parche que los cierra para no inflar la cifra. También aclaró que todo es código del kernel; el software de espacio de usuario que corre como root quedó fuera.
Lo que ya ha llegado al kernel
Aquí está la cautela que importa: 948 parches candidatos no son 948 fallos corregidos. Diez días después del escaneo, 61 escaladas estaban corregidas upstream, 43 tenían el parche en staging y 299 estaban en discusión o comunicadas públicamente. Siguiendo el consejo de la comunidad del kernel, OpenAI empezó por las críticas y envía el resto poco a poco con los socios de Patch the Planet, la iniciativa que lanzó en junio de 2026 con Trail of Bits y HackerOne, entre otros. Los exploits no se publican, y tampoco las diez técnicas de explotación que, según OpenAI, no conocían los expertos externos.
Cómo ha crecido en cinco meses
Lo más revelador es la progresión con el mismo enfoque:
| Ejecución | LPE | Coste en API |
|---|---|---|
| Lanzamiento de Patch the Planet (junio de 2026) | 24 PoC | — |
| Escaneo de finales de julio de 2026 | 166 | 513.690 $ |
| Escaneo de mediados de octubre de 2026 | 948 | 1.213.430 $ |
| kernelCTF de Google, kernel endurecido (112 horas) | 21 | 32.936 $ |
Entre julio y octubre el coste se multiplica por 2,4 y los exploits por 5,7. El autor del pipeline lo resumió así en Hacker News: los modelos más fuertes encuentran muchas vulnerabilidades que los más débiles no ven, y su plan es volver a escanear Linux con cada nueva generación. La fila de kernelCTF es el contrapunto: con un kernel endurecido y menos superficie expuesta, la cosecha cae a 21 exploits.
Qué se puede aprender
El código auditado caduca. Una revisión, humana o automática, vale lo que valía la herramienta que la hizo. Si un modelo de octubre encuentra casi seis veces más que uno de julio sobre el mismo código, el "ya lo pasamos por el analizador" deja de ser un argumento.
La validación es lo que escala. El embudo de 2.308 a 948 funciona porque cada paso exige algo ejecutable: un PoC que reproduce, un exploit que llega a root, un parche que lo cierra. Es el mismo principio que aplicamos con los tests de regresión, llevado a seguridad, y es lo que permite que los mantenedores reciban evidencias en lugar de avisos.
El cuello de botella pasa a ser el parcheo. Para quien opera Linux, el dato que más pesa es el 61 de 948. Vienen meses con un goteo constante de correcciones de escalada local en el kernel, y la exposición la marca cuánto tardamos en llevarlas a nuestros nodos. En clústeres multiinquilino, donde todos los contenedores comparten kernel, una LPE es una fuga de contenedor; ahí aislar con sandbox o máquinas virtuales ligeras y rotar nodos con rapidez cuenta más que nunca.
La superficie importa. La diferencia entre la ejecución general y kernelCTF dice que reducir lo que un usuario sin privilegios puede tocar sigue rindiendo.
Qué no es trasladable
El modelo no está disponible y el coste está fuera del alcance de casi cualquier equipo: 1,2 millones de dólares por una pasada sobre un solo proyecto. Tampoco hay datos públicos sobre las categorías de fallos ni sobre las técnicas nuevas, así que de momento no se pueden sacar patrones estructurales del kernel, algo que pedían varios comentarios en Hacker News. Lo que sí se puede copiar es la arquitectura: cada agente entrega una prueba verificable a la siguiente etapa, y una persona decide al final.
Fuentes
- A thousand fewer paths to root, OpenAI, 4 de noviembre de 2026.
- A thousand fewer paths to root: resumen del informe, AI/TLDR.
- OpenAI says its agents exploited and patched 948 Linux kernel flaws for $1.2M, Runtime Wire.
- OpenAI's AI pipeline turned 2,308 Linux kernel bugs into 948 root exploits, Startup Fortune.
- Discusión en Hacker News con los autores.