Falla crítica en Linux deja servidores expuestos: Ubuntu aún no tiene parche

Qué pasó

La falla está en la forma en que Linux abre conexiones TCP por IPv4, la base de casi todo el tráfico de internet. Existe desde 2016 (versión 4.4), la reportó Xinyang Ge, investigador de Anthropic, y se corrigió en el código oficial el 5 de octubre. El equipo del núcleo le asignó una gravedad de 9,8 sobre 10. IPv6 no se ve afectado.

El 27 de octubre, Anthropic informó que un modelo interno de Claude escribió un ataque que da control total del servidor en menos de una hora, aunque solo en equipos con una función de red llamada MPTCP activa. Hay matices: Anthropic no publicó el código, CloudLinux dice que no logró reproducirlo y, según The Hacker News, al 29 de octubre no había ataques reales reportados. Los fabricantes tampoco coinciden en la gravedad: Red Hat partió calificándola como moderada y después la subió.

Los parches llegan a distinto ritmo. Debian y Oracle Linux los publicaron el 16 de octubre, SUSE el 29 y Amazon Linux el 30. Red Hat lo hizo el 1 de noviembre para RHEL 8, 9 y 10. En cambio, Ubuntu 22.04, 24.04, 26.04 y 26.10 siguen "en proceso" y sin fecha. Según webhosting.today, AlmaLinux 9 y 10 y CloudLinux 9 y 10, muy usados con cPanel, tampoco tenían versión definitiva al 2 de noviembre.

Qué significa para tu empresa

En un hosting compartido con cPanel, el núcleo lo administra el proveedor y tú no puedes actualizarlo. Pero sí puedes preguntar, porque muchos de esos servidores usan justamente AlmaLinux o CloudLinux.

Si tienes un VPS o servidor propio, la tarea es tuya. Y hay un detalle que suele olvidarse: instalar el parche no basta. El núcleo nuevo solo se activa al reiniciar el servidor o con un parche "en caliente", como KernelCare. Un servidor que lleva meses sin reiniciarse puede tener la corrección descargada y seguir expuesto.

Los servicios hechos en Go 1.24 o posterior quedan en el grupo de mayor riesgo, porque ese lenguaje activa MPTCP por defecto cuando el sistema lo permite. Y el caso confirma lo que explicamos hace unos días: la IA acelera el hallazgo de fallas y el tiempo para reaccionar se acorta.

Qué puedes hacer

• Pregunta a tu hosting. Pide que confirme por escrito si sus servidores ya corren un núcleo con la corrección de CVE-2026-98432 o qué medidas temporales aplicó.
• Si tienes VPS con Debian, RHEL, Oracle Linux, SUSE o Amazon Linux, instala el parche, reinicia y confirma la versión activa con uname -r.
• Si usas Ubuntu, AlmaLinux 9 o 10, o CloudLinux 9 o 10, aplica una medida temporal mientras llega el parche: CloudLinux recomienda desactivar MPTCP (net.mptcp.enabled=0). Con ss -lMn ves qué servicios lo usan. Pruébalo antes en una copia.
• Revisa tus servicios en Go. Si no necesitas MPTCP, desactívalo con GODEBUG=multipathtcp=0. El equipo de Go advierte que es una medida frágil: el parche sigue siendo la solución.
• Programa el reinicio. Elige un horario de poco tráfico y avisa a tus clientes. Unos minutos fuera de línea planificados son mejores que un servidor comprometido.
• Vigila señales raras. Caídas o reinicios sin explicación, procesos desconocidos o un consumo de recursos fuera de lo normal.

Actualizaremos esta noticia cuando Ubuntu publique su corrección.