Los agentes de OpenAI encontraron 948 vías para obtener root en Linux, a 1279 dólares cada una

Imagine un servidor en el que el atacante solo tiene una cuenta modesta: por ejemplo, ha entrado en uno de sus contenedores o ha conseguido acceso a un entorno de pruebas. Una vulnerabilidad de clase LPE (local privilege escalation, escalada local de privilegios) convierte esa cuenta en root, es decir, en control total de la máquina. OpenAI buscó precisamente esos fallos en el kernel de Linux con ayuda de agentes autónomos.

De las 1724 vulnerabilidades confirmadas, 948 llegaron a exploits funcionales de escalada de privilegios, y toda la ejecución costó 1 213 430 dólares en créditos de API, unos 1279 dólares por cada exploit de este tipo. Si usted tiene Linux en producción, y la mayoría lo tiene, esta noticia le afecta directamente.

OpenAI ha publicado un análisis titulado «A thousand fewer paths to root» («mil caminos menos hacia root»). El trabajo lo hizo una cibermodelo que todavía no ha salido al mercado. El post la describe como «upcoming», así que es posible que su lanzamiento no esté lejos.

Cómo funciona el pipeline

Los investigadores no se limitaron a pedirle al modelo que «echara un vistazo al código». Construyeron a su alrededor un pipeline autónomo de varias etapas, parecido a una cuadrilla en la que cada uno se ocupa de lo suyo, pero sin personas:

• unos agentes eligen el fragmento de código que merece la pena revisar;
• otros lo escanean en busca de vulnerabilidades;
• otros reproducen lo encontrado en entornos aislados, para asegurarse de que el fallo es real y no una alucinación del modelo;
• la siguiente etapa comprueba si se puede explotar de verdad;
• la última genera los parches.

El paso de reproducción es aquí el más importante. El gran problema de los escáneres automáticos y de los revisores basados en LLM es que producen montañas de falsos positivos, y las personas se ahogan clasificando basura. Si cada hallazgo está confirmado por un exploit que funciona, el ruido desaparece: el bug se dispara o no se dispara.

Cifras y coste

Según el post, el pipeline se ejecutó sobre el kernel de Linux, al parecer solo en parte. Resultado: 1724 vulnerabilidades confirmadas y reproducidas, de las cuales 948 se convirtieron en exploits funcionales de escalada de privilegios.

La suma de 1 213 430 dólares parece elevada, pero el autor del post propone compararla con el mercado. En el concurso de hacking Pwn2Own se pagaban históricamente unos 20 mil dólares por un exploit de este tipo, y en TyphoonPWN, unos 70 mil. Si se multiplica por 948, salen entre 18,9 y 66,3 millones de dólares. Es decir, lo encontrado habría costado en esos concursos entre 15 y 55 veces más de lo que costó la ejecución de los agentes.

Salvedad: se trata de una estimación del autor del post, no de una lista de precios. Los premios de los concursos y el valor real de mercado de un exploit son cosas distintas, y los propios 948 hallazgos pueden diferir mucho en gravedad y en condiciones de aplicación. Conviene consultar los detalles en la fuente original.

Qué hacer en la práctica

Primero, cambia la economía de la búsqueda de vulnerabilidades. Antes, un exploit serio para el kernel requería semanas de trabajo de un especialista poco común. Ahora es una partida de gasto en API, y escala con dinero. Esto funciona en ambos sentidos: los defensores encuentran y cierran fallos más rápido, pero también baja la barrera de entrada para los atacantes, si tienen acceso a modelos comparables.

Segundo, es probable que se acorte la ventana entre la aparición de una vulnerabilidad y su explotación masiva. Posponer las actualizaciones del kernel en servidores y hosts de contenedores sale cada vez más caro, por lo que conviene revisar la política de parches.

Tercero, el enfoque es trasladable a su propio código. El esquema «encontrar, reproducir en un sandbox, confirmar la explotabilidad, proponer un parche» no se aplica solo al kernel. Para quienes construyen agentes de código y seguridad, lo esencial es esto: el valor no lo crea un único modelo potente, sino las etapas de verificación a su alrededor, que descartan los hallazgos falsos.

Lo que el post deja sin aclarar: cuántos de los fallos encontrados ya están corregidos en upstream, qué parte concreta del kernel se escaneó y cuándo y en qué condiciones saldrá el propio modelo. Por ahora es una demostración de capacidades potente, no un producto terminado. Pero la dirección está clara: la búsqueda automática de vulnerabilidades deja de ser un juguete y se convierte en un proceso industrial.