Ciberseguridad
CVE-2026-98432: qué revisar antes de dar tu Linux por protegido
Cómo funciona el fallo TCP del kernel de Linux, qué demuestra el ataque remoto y qué versiones lo corrigen. Comandos copiables y diferencias entre parche instalado y kernel activo.
Un fallo remoto que requiere comprobar el kernel real
CVE-2026-98432 afecta al manejo de conexiones TCP en el kernel de Linux. Puede provocar corrupción de memoria y denegación de servicio. Anthropic ha descrito además una prueba de ejecución remota como root contra un servidor con un listener Multipath TCP, sin credenciales ni interacción del usuario.
El registro se publicó el 15 de octubre. La decisión práctica es comprobar qué kernel ejecuta tu equipo y si su proveedor ha publicado el arreglo para esa rama. Instalar actualizaciones no demuestra por sí solo que el fallo esté corregido: el paquete puede seguir pendiente o el sistema puede continuar arrancado con el kernel anterior. El estado de versiones de esta guía se ha contrastado el 30 de octubre de 2026.
Qué ocurre y cómo llega a aprovecharse
El problema aparece al establecer ciertas conexiones TCP sobre IPv4. Dos operaciones pueden usar las mismas opciones de una conexión. Una libera esa memoria mientras otra todavía la está leyendo. Es un use-after-free, utilizar datos después de que su espacio haya quedado libre, provocado por una condición de carrera entre operaciones concurrentes.
El ataque descrito por Anthropic encadena una fuga de información con corrupción de memoria para terminar ejecutando una orden con privilegios de root. Es una demostración de sus investigadores en unas condiciones concretas, no una prueba de que cualquier servidor Linux expuesto sea explotable de esa misma manera. Tampoco acredita por sí sola una campaña de ataques reales.
El parche hace que la liberación espere al periodo de gracia de RCU, el mecanismo con el que esos lectores acceden a los datos. Así se evita destruirlos mientras siguen en uso. La corrección aborda la causa en el kernel; cambiar una aplicación web no sustituye ese arreglo.
Versiones corregidas del kernel de origen
El registro del equipo de Linux sitúa el origen del código afectado en la rama 4.4 y enumera estas versiones corregidas. La tabla sirve para esas ramas upstream. En un kernel de distribución, el arreglo puede llegar mediante un backport con otra numeración: no compares únicamente los primeros números de uname -r.
| Rama upstream | Primera versión corregida |
|---|---|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 | 7.3 |
Las distribuciones no publican el parche al mismo tiempo
Debian ya identifica paquetes corregidos en sus repositorios de seguridad. Ubuntu sigue marcando el paquete linux de las versiones indicadas como vulnerable, con correcciones en preparación. Los números que acompañan a work in progress son previstos: todavía no deben presentarse como paquetes publicados y seguros.
En SUSE hay paquetes publicados para productos concretos y otros siguen en preparación. La misma regla se aplica a RHEL: comprueba el aviso de tu producto y su errata, en lugar de trasladar la versión de Debian o de otro kernel al tuyo. Esta selección no cubre todas las variantes cloud, HWE, tiempo real o arquitecturas.
| Producto y paquete | Estado verificado |
|---|---|
| Debian 12, linux | Corregido en 6.1.190-1, repositorio de seguridad |
| Debian 13, linux | Corregido en 6.12.113-1, repositorio de seguridad |
| Debian 12, linux-6.12 | Corregido en 6.12.113-1~deb12u1 |
| Ubuntu 22.04, 24.04, 26.04 y 26.10, linux | Vulnerable; corrección en preparación |
| openSUSE Leap 16.0, kernel-default | Paquete publicado desde 6.12.0-160000.40.1 |
Primero identifica el sistema y el paquete activo
Ejecuta las consultas en el host Linux que necesitas proteger. La primera identifica la distribución y el kernel en ejecución. La segunda es para Debian o Ubuntu y muestra la versión instalada del paquete que corresponde a ese kernel. Si utilizas un kernel personalizado y el paquete no existe con ese nombre, tendrás que consultar su origen.
En un despliegue con contenedores Linux, revisa también el kernel del host o de la máquina virtual que los ejecuta. Renovar la imagen de la aplicación no actualiza ese kernel.
Consultar distribución y kernel activo
cat /etc/os-release
uname -rDebian o Ubuntu: paquete del kernel activo
dpkg-query -W "linux-image-$(uname -r)"Actualizar Debian y Ubuntu desde sus repositorios
Estos comandos renuevan el índice e instalan las actualizaciones disponibles. Revisa la operación antes de aceptarla. No fuerzan un cambio de distribución ni instalan un kernel descargado de una web externa. Deben estar habilitados los repositorios de seguridad correspondientes y no haber bloqueos que impidan actualizar el kernel.
En Debian, contrasta la versión del paquete con la tabla anterior y el aviso vigente. En Ubuntu, mientras el estado siga en preparación, ejecutar apt upgrade no convierte el sistema en corregido para este CVE. Habrá que aplicar el paquete cuando su aviso lo marque como publicado.
Debian o Ubuntu: instalar actualizaciones disponibles
sudo apt update
sudo apt upgradeEn RHEL, revisa la errata y aplica la actualización disponible
DNF permite listar las actualizaciones de seguridad e instalarlas desde los repositorios configurados. Para este CVE, confirma primero qué errata corresponde a tu producto y a su canal de soporte. Una lista vacía o un comando terminado correctamente no demuestran que ya exista el parche para tu kernel.
El bloque siguiente instala las actualizaciones de seguridad disponibles, no exclusivamente las de este fallo. En sistemas gestionados o clústeres, utiliza el procedimiento de mantenimiento de la plataforma.
RHEL: consultar e instalar actualizaciones de seguridad
sudo dnf updateinfo list updates security
sudo dnf update --securityDespués carga el kernel corregido y vuelve a comprobarlo
La vía habitual para usar el kernel recién instalado es reiniciar el equipo. Programa el reinicio, porque interrumpe sus servicios, y conserva acceso de recuperación si estás administrando un servidor remoto. El comando se presenta separado de la instalación para que no se ejecute como parte de una actualización copiada en bloque.
Al volver, consulta de nuevo el kernel activo y verifica su paquete frente al aviso del proveedor. Si utilizas livepatch, comprueba expresamente que cubre este CVE en tu kernel; tener el servicio activado no acredita esa cobertura.
Reiniciar cuando hayas programado la interrupción
sudo systemctl rebootTras reconectar: comprobar el kernel en ejecución
uname -r
Qué hacer mientras tu proveedor termina el parche
Reduce la exposición de los servicios que no necesitan acceso público y sigue el aviso de tu distribución. Es una medida de reducción de riesgo, no una corrección del fallo. Red Hat no publica una mitigación general que cumpla sus criterios de despliegue y estabilidad en el aviso consultado.
Tampoco deduzcas que estás protegido solo por un ajuste de MPTCP o de migración de sockets. El informe de explotación y el fallo general no tienen exactamente el mismo alcance. La conclusión útil es identificar el kernel, seguir el paquete de tu rama y comprobar que el arreglo está realmente en ejecución.