Canonical lleva semanas corrigiendo una vulnerabilidad crítica del kernel de Linux que Debian y otras distribuciones ya habían parcheado, y la demora ha indignado a buena parte de la comunidad de Ubuntu. Hasta hace unas horas, los kernels corregidos para Ubuntu 22.04, 24.04 y 26.04 LTS estaban en fase de pruebas, sin que la compañía haya dado una fecha para su llegada al canal de actualizaciones estables.
El fallo, registrado como CVE-2026-98432, es un error de tipo use-after-free en la parte del kernel que gestiona las conexiones TCP entrantes sobre IPv4, concretamente durante el protocolo de enlace o handshake. Según el boletín de seguridad de Red Hat, un atacante puede enviar datos manipulados a un sistema vulnerable para colapsarlo, lanzar una denegación de servicio o, en el peor de los casos, ejecutar código con privilegios de root. El equipo de CVE del kernel lo puntúa con un 9,8 sobre 10 en la escala CVSS 3.1; Oracle y SUSE lo rebajan a 8,1 porque lo consideran más difícil de explotar. Se cree que el fallo lleva presente desde 2016, lo que amplía enormemente el número de servidores y nubes potencialmente expuestos, muchos de ellos con Ubuntu. Si administráis alguno de estos sistemas, esto amplía el tiempo durante el cual permanecéis expuestos mientras el parche no llegue al canal estable.
Cuánto retraso lleva Canonical respecto a Debian
Debian integró el parche en su rama de seguridad semanas antes que Canonical, según registra su propio tracker. Canonical, por su parte, mantiene los kernels corregidos en pruebas desde el 3 de noviembre sin concretar cuándo llegarán al canal estable para 22.04, 24.04 y 26.04 LTS. Si os encargáis de administrar servidores Ubuntu, esa ventana sin parche oficial se traduce en días adicionales de exposición a un fallo que ya tiene explotación demostrada.
Canonical sí ofrece una vía más rápida para quien no quiera esperar: activar el repositorio -proposed, donde los kernels corregidos ya están disponibles aunque todavía en pruebas. La compañía recuerda que antes de publicar cualquier kernel lo somete a validación en miles de servidores y dispositivos certificados, un proceso que forma parte de su nueva cadencia de seguridad del kernel, pensada en teoría para sacar los parches más rápido.
Un modelo de Claude sin publicar convirtió el fallo en un exploit
El investigador de Anthropic que reportó el fallo asegura que un modelo de Claude todavía sin publicar llegó a construir un exploit funcional. El código aprovecha Multipath TCP (MPTCP) para dar a un atacante remoto acceso root en los servidores afectados, según recoge la propia investigación de Anthropic sobre el descubrimiento de vulnerabilidades con IA. La existencia de un exploit operativo generado de este modo ha añadido presión a una comunidad que ya veía con incomodidad que la solución no estuviera disponible en el canal estable.
A la severidad del fallo se suma que la corrección, según se ha compartido en redes sociales, consistiría en un cambio de apenas dos líneas en el código. Esa combinación, un error crítico con un parche sencillo que ya circula en otras distribuciones desde hace semanas, es la que ha disparado las críticas hacia Canonical en los últimos días.
Qué dice la comunidad de Ubuntu en redes sociales
En redes sociales las críticas no se han hecho esperar. «No hay ninguna explicación de por qué Ubuntu lleva semanas dormido al volante», escribió un usuario en X respondiendo a un mensaje de Canonical que anunciaba que estaba probando el kernel parcheado. «Descanse en paz, Ubuntu. Todos habéis estado dormidos al volante», le respondió otro usuario.
El malestar ha ido más allá de los comentarios sueltos. Un desarrollador publicó un artículo titulado «WTF Ubuntu» en el que explica que va a mover todos sus servidores fuera de la distribución. En el texto asegura que «hemos perdido por completo la confianza» en Ubuntu como plataforma segura y fiable para sus necesidades, un giro notable viniendo de alguien que hasta ahora la usaba en producción. Si gestionáis infraestructura crítica sobre Ubuntu, estos testimonios reflejan hasta qué punto se ha tensado la relación entre Canonical y parte de su base de usuarios, más allá del propio fallo técnico.
Canonical defiende su proceso de pruebas
Canonical defiende que prueba cada kernel en miles de servidores y dispositivos certificados antes de publicarlo, y que quien necesite el parche antes puede activar el repositorio -proposed. La compañía también descarta desactivar MPTCP como solución temporal: según explica, las actualizaciones de seguridad son «la única mitigación apropiada», porque el fallo no es exclusivo de esa función sino que afecta a la gestión general de TCP sobre IPv4.
Esa postura resulta algo paradójica porque es precisamente la nueva cadencia de seguridad del kernel que Canonical introdujo para acelerar los parches la que, en este caso, parece haber alargado la espera: el proceso de pruebas tiene una duración fija y los parches salen tan rápido como permite ese calendario, no tan rápido como exige un fallo con 9,8 de puntuación. Para quienes dependemos de Ubuntu en producción, el episodio golpea de lleno el argumento comercial de Ubuntu Pro y ESM, los paquetes de soporte con los que Canonical promete a empresas y nubes actualizaciones de seguridad a tiempo.
Mientras el parche no llegue al canal estable, el riesgo recae en vosotros si administráis los servidores: activar -proposed implica asumir paquetes todavía en pruebas, y no hacerlo supone mantener activo un fallo que Debian lleva semanas sin sufrir.