Ubuntu, más de dos semanas sin parche para un CVE 9.8

Un CVE 9.8 con exploit funcional y Ubuntu sigue sin parche

Debian publicó el parche el 16 de octubre. Ubuntu, más de dos semanas después, sigue listando cada una de sus versiones soportadas —LTS incluidas— como vulnerables. En el medio hay una falla de kernel con exploit funcional escrito por un modelo de IA.

Ese es el resumen de CVE-2026-98432, una condición de carrera en el código IPv4 TCP del kernel de Linux que deriva en un use-after-free: el kernel puede leer memoria que ya liberó. El error existe desde Linux 4.4, y por eso prácticamente cualquier servidor Linux del planeta está expuesto, según el reporte de The Hacker News.

Para un founder, la pregunta no es técnica. Es esta: si el sistema operativo que sostiene tu producto no parchea a tiempo, ¿de quién es el riesgo?

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué hace exactamente CVE-2026-98432?

La falla ocurre durante el handshake de TCP. Cuando una conexión se completa, el kernel entrega las IP options guardadas con la petición pendiente al nuevo socket sin copiarlas. Si ese socket se destruye mientras otra CPU todavía las usa para responder a una petición reenviada, el kernel lee memoria liberada.

Anthropic dijo el 27 de octubre que su modelo de IA escribió, tras un prompt inicial, un exploit en dos etapas: primero filtra una dirección del kernel y sortea KASLR; después desborda un buffer y sobrescribe un puntero de callback para ejecutar comandos como root. En su prueba, filtrar la dirección tomó 48 minutos y llegar a la ejecución de comandos, 5 minutos más, según The Hacker News. El ataque apunta a servidores con un listener de MPTCP (Multipath TCP).

El puntaje 9.8 que circula no es unánime, y esa diferencia importa:

El equipo CVE del propio kernel asignó 9.8 el 24 de octubre.
Red Hat puntúa la falla como Moderate 5.9 en su página, aunque su archivo de advisory del 29 de octubre la califica Important 8.1.
Amazon la puntúa 7.0; Oracle y SUSE, 8.1.
Todos coinciden salvo en un métrico: la complejidad del ataque, que los vendors califican alta y el equipo del kernel, baja.

Un dato que equilibra el pánico: al 1 de noviembre, AWS declaró en su boletín de seguridad que no tiene conocimiento de explotación de esta falla en el mundo real, y el CVE no figuraba en el catálogo de vulnerabilidades explotadas de CISA. El riesgo es serio; la emergencia activa, no confirmada.

Ubuntu es la excepción, no la regla

Lo que hace ruido no es la falla. Es quién parcheó y quién no.

El fix llegó al kernel upstream el 5 de octubre, diez días antes de que se publicara el CVE, según The Hacker News. A partir de ahí, las distribuciones empezaron a mover:

Debian: parcheado el 16 de octubre, con actualizaciones complementarias el 17 y el 22.
Oracle Linux: parcheado el 16 de octubre.
Amazon Linux 2023: paquete kernel6.18 corregido el 24 de octubre; kernel6.12, el 29.
SUSE Linux Micro 6.2 y openSUSE Leap 16.0: corregidos.
Ubuntu 22.04, 24.04, 26.04 y 26.10 LTS: work in progress, sin paquete al 29 de octubre. Las versiones 16.04, 18.04 y 20.04 figuran directamente como vulnerables, igual que sus kernels de cloud, FIPS y real-time.

El autor del post original va más lejos: señala que distribuciones mantenidas por voluntarios —Debian, Arch, Alpine— ya publicaron el fix, mientras que Ubuntu, vendido por una empresa que comercializa suscripciones de seguridad, todavía no. Ubuntu promete en su sitio parches oportunos para vulnerabilidades críticas.

Y no es un episodio aislado. Linux Journal reportó en septiembre de 2026 el caso de CVE-2026-80521, una falla de escape de contenedores con exploit público desde el 22 de septiembre, corregida upstream el 6 de agosto, que seguía marcada como vulnerable y en progreso en el tracker de Ubuntu 26.04 LTS.

Por qué Canonical no llega a tiempo

Help Net Security documentó que Canonical está unificando su ciclo de cuatro semanas para actualizaciones estables con el de dos semanas para correcciones de seguridad en un solo ciclo, que produce una publicación semanal de kernels. La compañía apunta a publicar mitigaciones dentro de 24 a 48 horas de la divulgación pública de una vulnerabilidad.

El problema es estructural y la propia Canonical lo admite: los lanzamientos expeditivos no son posibles si se testea a fondo cada release candidate. Su vía rápida es el pocket -proposed, builds sin certificar que las empresas adoptan bajo su propio riesgo. La letra chica es incómoda para cualquier equipo de infraestructura: el kernel más rápido que ofrece el proveedor es el que todavía no terminó de probar.

¿Qué significa esto para tu startup?

La mayoría de los founders hispanohablantes no eligió Ubuntu. Lo heredó: es el sistema por defecto de la mayoría de los proveedores de VPS y de las AMIs más comunes. Esa comodidad tiene un costo que casi nadie audita — tu ventana de parcheo no la controla tu equipo, la controla el proveedor del sistema operativo.

Tres consecuencias concretas:

LTS ya no equivale a seguro. LTS significa soporte largo, no respuesta rápida. Son dos cosas distintas y conviene separarlas al elegir infraestructura.
El riesgo se concentra. Si tu producto corre en contenedores multi-tenant, una falla alcanzable desde adentro del contenedor puede convertirse en un salto al host, como ilustró el caso de septiembre reportado por Linux Journal.
Migrar de urgencia es caro. El autor del post contó que tuvo que apagar servidores porque no le daba el tiempo para migrar datos y servicios. Planificar el cambio con calma cuesta una fracción de improvisarlo bajo presión.

Acciones que puedes ejecutar hoy

1. Haz inventario del kernel real, no del nombre de la distro. El nombre de la versión no dice nada por sí solo: los kernels HWE y los específicos de cloud (AWS, Azure, GCP, Oracle, KVM) tienen estados distintos en el tracker del proveedor. En cada host:

uname -r para ver el kernel activo.
dpkg -l 'linux-image*' para ver los paquetes instalados.
Compara el paquete exacto contra el aviso del proveedor antes de asumir que estás cubierto.

2. Aplica mitigaciones interinas mientras esperas el parche. AWS publicó en su boletín tres medidas que reducen las condiciones del ataque, aunque no lo resuelven:

Desactivar MPTCP en el kernel con net.mptcp.enabled=0.
Bloquear paquetes IPv4 que llevan IP options con una regla de iptables: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP.
Para aplicaciones en Go 1.24 o superior, definir GODEBUG=multipathtcp=0 en el entorno (o godebug multipathtcp=0 en go.mod).

Ojo con confiar de más en la tercera: el equipo de seguridad de Go la calificó de mitigación frágil, porque un solo listener MPTCP expuesto deja el sistema vulnerable y el bug de fondo no es exclusivo de MPTCP, según The Hacker News.

3. No olvides el reboot. Cuando el parche llegue, instalar el paquete no cambia el kernel que está corriendo en memoria: hay que reiniciar para que la corrección tenga efecto. AWS lo repite en cada línea de su boletín. En un clúster con alta disponibilidad, eso significa drenar nodos, actualizar, reiniciar y verificar el kernel activo antes de devolverlos al servicio.

4. Evalúa el proveedor, no solo la distro. Para la infraestructura nueva conviene mirar quién parcheó y en cuántos días. En esta ronda, Debian, Oracle Linux, SUSE y Amazon Linux publicaron paquetes corregidos; Ubuntu y RHEL no. Ese historial es información de compra.

Conclusión

CVE-2026-98432 es una falla grave, con exploit funcional y alcance remoto, pero al 1 de noviembre AWS reportaba que no hay explotación confirmada en el mundo real. No es motivo para apagar todo.

Sí es motivo para revisar una dependencia que casi nadie cuestiona: el sistema operativo que elegiste por comodidad y que ahora define tu tiempo de exposición. La lección del post original no es sobre Ubuntu en particular, sino sobre confiar en palabras —oportuno, grado empresarial— sin mirar el tracker de seguridad.

Mide tu exposición, aplica la mitigación interina, verifica el paquete exacto en cada host y toma la decisión de migración con datos. Es el tipo de trabajo aburrido que separa una startup que aguanta de una que aparece en las noticias por la razón equivocada.