Greg Kroah-Hartman, mano derecha de Linus Torvalds: "El número de problemas en Linux detectados por la IA no deja de crecer. Nos esperan 18 meses muy largos para salir de este caos"
La avalancha de fallos hallados con IA desborda al equipo del kernel Linux y obliga a replantear cómo se revisan, priorizan y aplican las actualizaciones de seguridad.
Linux lleva años sometido a revisiones constantes, pero la llegada de herramientas de inteligencia artificial capaces de analizar enormes cantidades de código está cambiando por completo el ritmo al que aparecen los fallos.
Errores que antes podían permanecer ocultos durante años ahora salen a la luz con mucha más frecuencia, lo que mejora la seguridad a largo plazo, aunque también está generando una avalancha de informes que los mantenedores apenas pueden revisar al mismo ritmo.
La magnitud del problema quedó clara cuando el equipo responsable del kernel publicó 432 vulnerabilidades CVE en solo dos días. No todas eran críticas ni habían sido descubiertas mediante IA, ya que Greg Kroah-Hartman explicó que buena parte correspondía a una cola de trabajo acumulada durante varias semanas.
Sin embargo, este episodio dejó claro que el proceso actual puede quedar desbordado cuando cientos de avisos llegan prácticamente al mismo tiempo, y que al final puede convertirse en un total caos para todos los mantenedores del núcleo Linux.
La IA ya encuentra fallos que antes podían pasar años ocultos
Durante mucho tiempo, muchos informes generados con modelos describían errores inexistentes o problemas mal interpretados, lo que obligaba a los mantenedores a perder horas comprobando resultados que no aportaban nada.
Kroah-Hartman asegura que eso está cambiando porque las herramientas actuales pueden seguir rutas de ejecución complejas, detectar comportamientos sospechosos y señalar zonas del kernel que merecen una investigación real.
Cada hallazgo sigue necesitando una revisión humana, pero la calidad de los resultados ha mejorado de forma evidente, y GhostLock es uno de los ejemplos más claros.
Esta vulnerabilidad, registrada como CVE-2026-43499, llevaba unos 15 años presente en Linux hasta que fue localizada mediante VEGA, una plataforma de Nebula Security asistida por IA.
Cabe señalar que el fallo podía facilitar una escalada de privilegios y permitir que un atacante obtuviera acceso root en determinadas condiciones.
Los 432 CVE no significan que todos los sistemas estén expuestos
Un identificador CVE puede corresponder a una vulnerabilidad grave, aunque también puede afectar únicamente a un controlador concreto, una función poco utilizada o una configuración muy específica, de modo que no todas las organizaciones tienen que tratar los 432 avisos como si representaran el mismo nivel de riesgo.
La dificultad está en determinar cuáles afectan realmente a cada infraestructura. Para hacerlo, las empresas deben comparar las correcciones con los componentes que utilizan y comprobar que cada parche no provoque incompatibilidades, algo delicado cuando se trata de equipos que deben permanecer operativos.
Jan Schaumann, arquitecto jefe de seguridad de Akamai, considera que estudiar manualmente cientos de cambios ha dejado de ser una estrategia realista, por lo que defiende actualizar con mayor frecuencia y depender menos de una selección individual de parches.
El problema es que muchas organizaciones necesitan probar cada cambio antes de instalarlo. Una corrección puede cerrar una vulnerabilidad y, al mismo tiempo, romper un controlador o afectar a una herramienta interna que resulta esencial para el funcionamiento diario.
Greg Kroah-Hartman cree que las empresas deben utilizar versiones mantenidas y apoyarse en distribuciones capaces de probar las actualizaciones antes de publicarlas.
También pueden automatizar la comparación entre los archivos modificados y los componentes presentes en cada sistema para reducir el número de casos que requieren una revisión manual.
Los próximos 18 meses cambiarán la forma de mantener Linux
Kroah-Hartman respondió que el problema no está solo en la cantidad de vulnerabilidades, sino en unos procesos de mantenimiento demasiado lentos para el nuevo ritmo de descubrimiento.
Por ello, recomienda utilizar versiones soportadas, aplicar actualizaciones completas, así como confiar en distribuciones o proveedores capaces de probarlas.
También recuerda que una empresa no necesita tratar todos los CVE como si afectaran a sus sistemas. Comparar automáticamente los archivos modificados con los componentes instalados puede reducir de forma importante el número de casos relevantes.
Cuando habla de “18 meses muy largos”, no promete que después dejarán de aparecer fallos. Se refiere al tiempo mínimo que puede necesitar el ecosistema para absorber la acumulación y adaptar los procesos de revisión y actualización.
La IA no está haciendo Linux más inseguro, sino que está sacando a la luz problemas que ya existían. El caos aparece porque la seguridad todavía responde con métodos diseñados para una época en la que los errores se descubrían mucho más despacio.