948 vulnerabilidades en el kernel de Linux: el problema ya no es encontrarlas, es parchearlas
El 4 de noviembre OpenAI publicó 948 vulnerabilidades en el kernel de Linux, cada una con un exploit que funciona y un parche escrito, todas salidas de una sola ejecución. Lo incómodo no es que existan: es que nadie tiene tiempo de revisar los parches.
El informe se llama "A thousand fewer paths to root" y describe un pipeline autónomo de agentes. El número grande es el titular, pero la historia real está en el embudo que hay detrás y en lo que pasa después.
Qué encontró exactamente el pipeline
Los 948 hallazgos son fallos de escalada de privilegios local, o LPE: alguien que ya tiene una sesión en la máquina con permisos limitados puede usarlos para llegar a root.
Escalada de privilegios local: hay que estar dentro para usarlo
No son vulnerabilidades de ejecución remota. Nadie entra a tu servidor por abrir un puerto. El riesgo aparece cuando ya hay alguien dentro o cuando varias personas comparten la misma máquina: hosting compartido, contenedores con aislamiento débil, runners de CI, escritorios gestionados. Ahí una LPE convierte un acceso menor en control total.
Lee también
El embudo: 2.308 candidatos, 1.724 reproducidos, 948 únicos
El pipeline no empieza encontrando fallos, empieza descartando. De 2.308 candidatos, 1.724 se reprodujeron; de ahí salieron 1.169 exploits LPE funcionales y 291 pruebas de fuga de información. Después vino el análisis de variantes, que agrupa los exploits que atacan la misma raíz, y quedaron 948 fallos únicos. Ese filtrado es lo que separa mil doscientos reportes de novecientos problemas.
Qué significa "parche candidato" y qué significa "fusionado"
Un parche candidato es una propuesta enviada a los mantenedores. No está en el kernel. Los reportes salieron empezando por los más críticos, coordinados con el programa de respuesta de OpenAI, y ahí empieza otra cola: la de revisión.
Cómo se valida un fallo sin equivocarse
La parte metodológica del informe importa más que el conteo, porque explica por qué un agente que "cree" haber encontrado algo no vale nada.
Explotar es la prueba: si no consigues root, no es un reporte
El criterio es duro: si el exploit no consigue privilegios de root en un entorno real, el hallazgo se descarta. Nada de "posible condición de carrera" sin demostración, que es la mayoría de los falsos positivos que queman tiempo de los equipos de seguridad.
El error de la primera ejecución: root por una vulnerabilidad distinta
En una corrida temprana el agente consiguió root, pero por un fallo diferente al que tenía asignado. El exploit funcionó y la explicación era falsa. Es el error clásico de la automatización sin validación cruzada, y la razón por la que todo pasa por revisión humana antes de salir del laboratorio.
Las diez técnicas que los expertos no habían visto
El informe menciona diez patrones de explotación que revisores externos del kernel no tenían catalogados. La consecuencia práctica: la búsqueda sistemática sobre cuarenta millones de líneas encuentra clases de error que la revisión manual, hecha con prisa, no estaba viendo.
Cuánto costó y por qué ese número importa
1.213.430 dólares en créditos de API para una ejecución
Es el cómputo declarado del pipeline completo. No es una factura pagada, es lo que habrían costado esos tokens a precio de lista.
Unos 1.279 dólares por fallo único
Dividido por los 948 hallazgos, cada vulnerabilidad sale a poco más de mil doscientos dólares, con exploit funcionando y parche escrito. Un equipo humano de tres o cuatro personas investigando LPE durante meses cuesta más y cubre menos superficie. No reemplaza al equipo: cambia el orden de magnitud de un paso del proceso.
El cuello de botella se mudó al parche
Aquí está el problema real, y no lo causó OpenAI.
Un kernel que va camino de 2.000 CVE por release
El kernel ronda los cuarenta millones de líneas y se encamina a dos mil CVE por ciclo. El volumen de reportes crece más rápido que la capacidad de revisarlos.
"We are completely overwhelmed": lo que dicen los mantenedores
En el pull request de red del ciclo 7.3, Jakub Kicinski estimó que entre un tercio y la mitad de los 648 parches de net-next parecían arreglos de baja prioridad o limpiezas generadas por IA, y lo resumió así: están completamente desbordados. Torvalds, por su parte, ha dicho que Linux no es un proyecto anti-IA y que quien no la quiera puede hacer fork. Ninguna de las dos posturas resuelve el problema práctico: decidir qué parche entra sigue siendo trabajo humano.
Qué hacer si administras servidores Linux
Prioriza por exposición: contenedores, hosting compartido y CI primero
Donde hay varios usuarios o inquilinos sobre el mismo kernel, una LPE pesa más. Ahí conviene parchear rápido, sin esperar la ventana mensual.
Kernel al día: LTS, ventanas de parcheo y reinicios planificados
Lo que ya haces en el deploy de un VPS sigue aplicando: kernel actualizado y una ventana en la que ya sabes cuánto tarda en volver el servicio.
Reduce la superficie: usuarios, SUID y lo que corre como root
Cada binario con SUID y cada servicio que corre como root es un punto de partida para una LPE. La guía de hardening de Linux cubre ese inventario. Y un kernel parcheado no arregla un endpoint sin autorización: el checklist de seguridad en producción sigue siendo la primera línea, porque casi todos los incidentes reales entran por ahí.
Qué significa si escribes código
Si tu equipo revisa parches de dependencias a las apuradas un viernes, el cuello de botella del kernel es el tuyo en pequeño. La capacidad de revisar es el activo escaso, no la de encontrar. Y si metes agentes en tu CI, mide cuántos reportes resisten verificación antes de mirar cuántos hallazgos produjo: el caso del exploit que llegó a root por el bug equivocado es el mejor argumento para no confiar en el primer resultado.
Conclusión
Encontrar fallos se volvió barato. Decidir cuáles importan, escribir el parche correcto y publicarlo bien sigue siendo caro, y ese es el mismo cuello de botella que tienes tú cuando llegan quince avisos de dependencias el mismo lunes.
Lo que hay que seguir de cerca: cuántos de los 948 parches se fusionan y si el flujo de reportes del kernel cambia para absorber volumen. La noticia no es que la IA encontrara 948 caminos a root; es que después de encontrarlos, el trabajo pesado recién empieza. En el blog seguimos siguiendo estos informes con números y sin humo.
