Ubuntu publicará núcleos cada semana; Canonical no da abasto ante la avalancha de nuevas vulnerabilidades CVE.

El flujo de vulnerabilidades detectadas se volvió tan denso que el anterior ritmo de actualizaciones del núcleo de Ubuntu dejó de satisfacer a Canonical. La empresa está trasladando los núcleos estables a un nuevo esquema SRU: en lugar del ciclo habitual de actualizaciones de cuatro semanas y del ciclo de seguridad separado de dos semanas, quedará un único proceso de dos semanas.

La publicación semanal no significa que Canonical reduzca todas las verificaciones del núcleo a siete días. Los ciclos de dos semanas se iniciarán con un intervalo de una semana y se solaparán. En la primera semana, el equipo recopila paquetes, realiza comprobaciones básicas de arranque y publica candidatos en el repositorio -proposed. La segunda semana se dedica a la certificación de hardware, pruebas de integración y regresión.

La transición comenzará el 28 de septiembre de 2026 con dos ciclos de dos semanas consecutivos. Otro comenzará el 12 de octubre, y a partir del 26 de octubre Canonical pondrá en marcha un esquema solapado. Tras desplegar esa cadena de montaje, los nuevos núcleos estables podrán publicarse cada semana, aunque cada uno seguirá un recorrido completo de dos semanas.

Canonical relaciona la aceleración sobre todo con el fuerte aumento del número de CVE. Los grandes modelos lingüísticos y los agentes de IA especializados han automatizado la búsqueda de errores en el código y permiten encontrar problemas más rápido que el análisis manual. Esta tendencia ya se vio en Linux: la vulnerabilidad CopyFail en 2026 fue encontrada por una herramienta de IA, después de lo cual se desarrolló un método funcional para elevar privilegios.

Sin embargo, la IA explica solo parte del aumento. En febrero de 2024 kernel.org obtuvo el estatus de CVE Numbering Authority y comenzó a asignar por sí mismo identificadores a problemas potenciales del núcleo. Los desarrolladores de Linux utilizan deliberadamente un enfoque cauteloso: debido al papel del núcleo, casi cualquier error podría teóricamente afectar a la seguridad, incluso si la vía de explotación no es evidente en el momento de la corrección.

Ese enfoque aumentó drásticamente el número de entradas que las distribuciones tienen que analizar. La documentación de Linux advierte por separado que muchos CVE asignados no son aplicables a un sistema concreto, ya que este utiliza solo una parte de la enorme base de código del núcleo. Para Canonical, el aumento aún significa más trabajo en la evaluación, el portado de correcciones a las ramas compatibles, la compilación y la verificación de los paquetes de Ubuntu.

La magnitud se aprecia bien en los boletines recientes de Ubuntu. Solo una publicación para el núcleo de Azure del 22 de septiembre enumeraba más de 1400 CVE corregidos, y otras actualizaciones del mismo día contenían decenas y cientos de entradas. Al mismo tiempo, no se puede evaluar el riesgo solo por el número de identificadores: parte de los errores no afectan a configuraciones concretas, mientras que problemas concretos de Linux ya se usan en ataques reales.

Los administradores que necesiten las correcciones más rápido podrán tomar los candidatos del núcleo desde -proposed ya después de la primera semana y realizar sus propias pruebas de aceptación. Ese camino reduce la espera a aproximadamente una semana, pero traslada parte de la verificación al propietario de la infraestructura. Para el canal estable normal, Canonical mantiene el conjunto completo de pruebas de certificación y regresión.

Antes de la publicación del núcleo final, Canonical planea publicar medidas temporales seguras, cuando existan, o recomendaciones para reforzar la protección. La compañía se fija el objetivo de llevar el sistema a un estado más protegido en un plazo de 24–48 horas tras la divulgación pública del problema. Las medidas temporales no sustituyen la actualización del núcleo, pero deben reducir el intervalo entre la divulgación de la vulnerabilidad y la publicación de la corrección verificada.