La IA de OpenAI encontró 948 fallos en el kernel de Linux y escribió los parches por $1,2 millones

Imagine un servidor Linux corriente: un usuario con privilegios mínimos que, por un error en el kernel, puede convertirse en administrador y hacerse con el control de toda la máquina. Estos errores se llaman LPE (local privilege escalation), es decir, escalada local de privilegios. OpenAI informó de que sus investigadores han montado un pipeline autónomo que busca por sí solo este tipo de fallos en el kernel de Linux, escribe exploits funcionales para ellos y prepara las correcciones.

En una sola ejecución, un modelo todavía no lanzado confirmó y preparó parches para 948 vulnerabilidades, y la factura por el uso de la API fue de unos $1,2 millones. Como referencia, según un empleado de OpenAI, los investigadores suelen encontrar unos 20 fallos de este tipo al año. Si usted es responsable de servidores, contenedores o infraestructura en la nube sobre Linux, esto indica que el ritmo de búsqueda de vulnerabilidades está cambiando.

Qué hizo exactamente OpenAI

El pipeline cubre todo el ciclo: detección de la vulnerabilidad, explotación y parche. No se limita a avisar de que «aquí puede haber algo raro», sino que comprueba que el fallo realmente se puede explotar y solo entonces propone la corrección. Esto importa a los mantenedores del kernel, que suelen verse desbordados por los falsos positivos de los escáneres automáticos.

OpenAI afirma además que los agentes encontraron y aplicaron al menos 10 técnicas de explotación del kernel de Linux que el equipo y los expertos invitados consideran nuevas. Según la compañía, esto demuestra que los modelos no se limitan a repetir métodos conocidos, sino que inventan los suyos. Se trata de una afirmación de la propia OpenAI y por ahora no hay verificación independiente.

Cuánto cuesta

La factura total de la API ronda los $1,2 millones. Greg Brockman cifra el coste en aproximadamente $1 000 por vulnerabilidad; si se divide sin más $1,2 millones entre 948, el resultado es de unos $1 300. Eric Wallace afirma que el modelo encontró alrededor de mil LPE en una semana, con un gasto de aproximadamente $1 millón en tokens. Según él, OpenAI destina ahora un «volumen significativo» de cómputo de frontera a corregir gratuitamente vulnerabilidades en código abierto.

La evolución también es reveladora. En una de las comparaciones, GPT-5.6 Sol encontró en julio de 2026 166 vulnerabilidades por aproximadamente $500 mil, es decir, unos $3 000 por pieza. El nuevo modelo cerró 948 fallos por $1,2 millones: casi seis veces más fallos, y el coste de cada hallazgo cayó a menos de la mitad. Un comentarista opina que el coste interno real es aún inferior al precio de la API, pero es una estimación no confirmada.

Qué hacer en la práctica

Primero, OpenAI trabaja con los mantenedores de Linux y con los socios de Patch the Planet en los informes y los parches. Cabe esperar una oleada de actualizaciones del kernel, así que conviene afinar de antemano el proceso para desplegarlas rápidamente en sus servidores.

Segundo, si un modelo encuentra mil LPE en una semana, tarde o temprano capacidades similares estarán también en manos de los atacantes. La ventana entre la aparición de un fallo y su explotación se estrecha, por lo que las actualizaciones rápidas, el aislamiento de las cargas de trabajo y el principio de mínimo privilegio dejan de ser un punto de una lista de comprobación y pasan a ser una necesidad.

Tercero, para quienes desarrollan herramientas de seguridad: el listón ha subido. El valor ya no está en un escáner que muestra sospechas, sino en un agente que demuestra la vulnerabilidad y aporta el parche listo.

Salvedades

El modelo utilizado no se ha publicado y se mantiene al margen de los rumores sobre GPT-6.2 Sol y Astra, por lo que el resultado no se puede reproducir desde fuera. Todas las cifras proceden de OpenAI y de sus empleados. No está claro cuántos de los 948 hallazgos considerarán críticos los mantenedores y cuántos resultarán de bajo riesgo o duplicados. Pero incluso con estas salvedades, la conclusión es relevante: la búsqueda de vulnerabilidades en el kernel depende cada vez más del presupuesto de cómputo y no solo del número de expertos.