Linux ya suma 7.900 vulnerabilidades en 2026 y la causa más citada no cierra

El kernel de Linux, el núcleo del sistema operativo que corre en servidores, nubes y celulares Android, lleva casi 7.900 vulnerabilidades registradas con identificador CVE en lo que va de 2026. Son el 38 % de las casi 21.000 publicadas desde 1997, según LinuxCVETracker, un sitio independiente que ordena los datos de la Base Nacional de Vulnerabilidades (NVD) de Estados Unidos.

La explicación más repetida para el salto apunta a una sola opción de configuración. Sergio de los Santos, investigador con más de veinte años en seguridad informática y director de Innovación y Laboratorio de Telefónica Tech, la puso a prueba con los mismos datos y lo contó en un hilo en su cuenta personal de X el 19 de octubre. Las conclusiones son suyas, no de la empresa. Según el especialista, su medición no confirma que esa opción explique la mitad de los CVE del kernel.

Por qué un reinicio cuenta como falla de seguridad

Desde el 13 de febrero de 2024, el proyecto del kernel es una CNA (autoridad de numeración de CVE), es decir que asigna él mismo los identificadores de sus fallas. El equipo tiene tres integrantes centrales, que revisan cada corrección que llega a las versiones estables y deciden cuáles encajan en la definición de vulnerabilidad del programa CVE. Esa definición incluye cualquier falla que afecte la disponibilidad de un sistema.

Ahí entra WARN(), la instrucción con la que el kernel avisa en su registro que pasó algo inesperado y sigue funcionando. Con la opción panic_on_warn activada, ese mismo aviso detiene el sistema por completo (un kernel panic) y obliga a reiniciarlo. La documentación del kernel la presenta como una herramienta para depurar errores. Greg Kroah-Hartman, mantenedor de las versiones estables del kernel y miembro del equipo de CVE, la describe como una defensa que muchos activan porque prefieren reiniciar antes que dejar seguir un sistema con un error.

La consecuencia la explicó él mismo en su blog el 16 de febrero de 2026. "Por esta configuración, cualquier corrección del kernel que resuelva un WARN_ON que un usuario pueda disparar debe recibir un CVE. Si esta opción no existiera, el número total de CVE asignados por Linux caería mucho", escribió. En diciembre de 2025, en un comentario en el sitio LWN, fue más lejos sobre el alcance. Dijo que hay "miles de millones de sistemas Linux" con la opción activada, "la enorme mayoría de Linux", y que provocar ese reinicio es una denegación de servicio. "Ojalá no fuera así", agregó.

En su hilo, De los Santos atribuye a Kroah-Hartman la estimación de que, sin esa opción, los CVE caerían "probablemente bastante más de la mitad". En los textos publicados de Kroah-Hartman sobre el tema (su blog, sus comentarios en LWN y sus mensajes en la lista del kernel), la frase que aparece es que el total "caería mucho", sin porcentaje. La cifra puede venir de alguna charla o intervención que no está publicada por escrito.

Su medición: menos del 1 % de los casos

De los Santos buscó en las descripciones de los CVE de LinuxCVETracker. Solo 39 de 17.383 (el 0,2 %) atribuyen el impacto a panic_on_warn, y sumando las que mencionan un WARNING: o un WARN_ON no llegó al 12 %. Él mismo aclaró que es "una estimación que habría que afinar" y que la opción quizás no siempre se menciona. Una búsqueda en el mismo sitio el día del hilo devuelve unos 60 CVE con panic_on_warn en la descripción, menos del 0,5 % del total.

Las dos cifras del hilo no miden lo mismo. Los 20.869 de la captura son todos los CVE del kernel que el sitio registra desde 1997. Los 17.383 son la base de su consulta, y el autor no explicó el recorte. En el mismo sitio, los CVE escritos con el formato que usa la CNA del kernel desde 2024 suman unos 17.800, una cifra cercana.

La medición tiene un límite que el propio especialista reconoce. Una corrección que elimina un WARN_ON puede recibir un CVE sin que su descripción nombre la opción, y Kroah-Hartman habla de esas correcciones, no de las palabras de cada texto. Ninguno de los dos publicó un conteo completo.

Google desmiente que Android active la opción

El otro punto en disputa es quién tiene la opción encendida. Kroah-Hartman escribió en julio de 2024 que "unos pocos miles de millones de teléfonos" la tienen activada, y De los Santos retoma ese dato en su hilo, citándolo a él. Eric Biggers, desarrollador del kernel que trabaja en Google, lo negó en abril de 2024 en la lista del kernel. "No es cierto que Android active esta opción", escribió, y aclaró que algunos fabricantes pueden haberla elegido por su cuenta, pero que "no se usa por defecto ni se recomienda".

La configuración de referencia del kernel genérico de Android (GKI), publicada por Google, le da la razón en lo que se puede comprobar. No activa panic_on_warn, aunque sí reinicia el sistema ante un error grave del kernel, un caso distinto. Qué hace cada fabricante en sus equipos no está documentado en público.

Un sistema de alertas que ya no da abasto

El volumen ya presiona a todo el sistema que registra y ordena las vulnerabilidades. En lo que va de 2026, el kernel publica en promedio unos 27 CVE por día, y quien decide cuáles lo merecen es un equipo de tres integrantes centrales. Del otro lado, el 15 de abril el NIST, el instituto de normas de Estados Unidos que administra la base, dejó de analizar todos los CVE porque los envíos crecieron un 263 % entre 2020 y 2025. Ahora prioriza los que figuran en el catálogo de vulnerabilidades explotadas de la agencia CISA y los del software que usa el Gobierno federal.

En LinuxCVETracker, el 37 % de los CVE del kernel de 2026 todavía espera la puntuación del NVD. Son señales tempranas de un sistema que registra vulnerabilidades más rápido de lo que puede evaluarlas.

Con el NVD atrasado, la región prioriza parches por su cuenta

Android corre en el 83,5 % de los celulares de Sudamérica, según StatCounter para septiembre, así que la decisión de cada fabricante sobre esta opción pesa en la región más que en otras. Para los equipos de seguridad que ordenan sus parches según la gravedad que asigna el NVD, el atraso deja más de un tercio de los CVE del kernel de este año sin una puntuación oficial.

El catálogo de explotadas de CISA, en cambio, incluye solo 31 vulnerabilidades del kernel en toda su historia, una lista corta para arrancar. En medio de la avalancha también aparecen vulnerabilidades graves de verdad, como PwnEscape, que deja leer la memoria del servidor desde sus máquinas virtuales. La recomendación del equipo del kernel es actualizar a la última versión estable en lugar de elegir parches uno por uno. "Los números puros de CVE no importan, lo que importa es tu caso de uso", escribió Kroah-Hartman.

De los Santos cierra su hilo con su lectura de que los CVE "ya no son lo que eran", por esta y otras razones, como la crisis del NIST. La discusión sigue abierta dentro del propio kernel. En julio, Keith Busch, mantenedor del soporte NVMe del kernel, propuso en la lista una variante del aviso que no provoque el reinicio, para poder "aliviar la carga de CVE".