Red Hat publicó el viernes 30 de octubre de 2026 el boletín RHSB-2026-016 sobre CVE-2026-98432, una vulnerabilidad del kernel de Linux en el manejo de conexiones TCP sobre IPv4, y la calificó como crítica, con CVSS 9.8 (preliminar). Es el peor tipo de falla para un servidor: remota, sin usuario, sin contraseña y sin que nadie haga clic. Un atacante que pueda mandarle paquetes a tu servidor puede, como mínimo, tumbarlo; en el peor caso, ejecutar código.
El problema es el calendario: a este sábado 31 de octubre, Ubuntu y Red Hat todavía no tienen kernel corregido para sus versiones principales. Debian sí. Así que el fin de semana toca mitigar y dejar lista la actualización.
Qué se sabe
| Dato | Detalle |
|---|---|
| Vulnerabilidad | CVE-2026-98432 |
| Componente | Kernel de Linux, código TCP de IPv4 |
| Tipo | Uso de memoria liberada (use-after-free) por condición de carrera |
| Calificación | CVSS 9.8 (Red Hat y Ubuntu); Red Hat la marca como crítica |
| Requisitos | Ninguno: remota, sin autenticación ni interacción |
| Versiones | Kernels desde la 4.4, según BleepingComputer |
| Explotación en ataques reales | No confirmada al 30 de octubre |
| Parche | Debian sí; Ubuntu y RHEL en preparación |
La falla, explica Red Hat, aparece cuando el kernel procesa al mismo tiempo solicitudes de conexión TCP retransmitidas o migraciones de sockets: libera las opciones del socket mientras todavía se están usando. Ubuntu, que la publicó el 15 de octubre y actualizó su ficha el 30, aclara que IPv6 no está afectado por el problema principal.
Sobre la gravedad hubo idas y vueltas. BleepingComputer reportó que Red Hat la había calificado con 5.9, como posible denegación de servicio, por lo difícil de explotarla. Su ficha actual dice otra cosa: 9.8, crítica, porque no requiere credenciales y los servicios TCP por defecto quedan expuestos, aunque reconoce que ejecutar código de forma confiable exige un control preciso de la memoria.
Por qué subió el tono
Según BleepingComputer, Anthropic informó que un modelo de Claude aún no lanzado construyó en unos 53 minutos un exploit que esquivó las protecciones de memoria (KASLR) y ejecutó comandos como root en un servidor Linux con un listener MPTCP (TCP multiruta). Sin MPTCP no se ha demostrado ejecución remota, pero la falla también afecta al TCP normal.
Un detalle práctico que menciona el mismo reporte: Go 1.24 y posteriores activan MPTCP por defecto en los listeners TCP en Linux cuando el kernel lo soporta. Servicios escritos en Go podrían tener MPTCP expuesto sin que nadie lo sepa. Ojo: desactivar MPTCP no basta, porque el TCP ordinario también dispara la falla.
¿Mi distribución ya tiene parche?
Estado al 30 de octubre de 2026, según las fichas de Ubuntu y Red Hat y el resumen de BleepingComputer:
| Distribución | Estado |
|---|---|
| Debian 12 | Corregido en kernel 6.1.190-1 |
| Debian 13 | Corregido en kernel 6.12.113-1 |
| Ubuntu 22.04, 24.04, 26.04 y 26.10 | Vulnerable; parche en preparación |
| Ubuntu 16.04, 18.04 y 20.04 | Vulnerable (sin versión en preparación listada) |
| RHEL 8, 9 y 10, OpenShift | Afectado; Red Hat acelera las correcciones |
| RHEL 7 | No afectado, según BleepingComputer |
| Rocky Linux 8, 9 y 10 | Afectado |
| Oracle Linux, Amazon Linux, SUSE | Correcciones para algunas versiones |
Ojo con los appliances que corren Linux por dentro (NAS, conmutadores telefónicos, NVR): dependen de que el fabricante saque firmware.
Mitigación mientras sale el kernel
Red Hat publicó una regla de nftables que descarta los paquetes TCP sobre IPv4 con opciones de IP (encabezado IP mayor a 20 bytes), que es lo que necesita el ataque. Se guarda en un archivo, por ejemplo cve-2026-98432.nft:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}
Y se valida y aplica así:
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
Tres advertencias del propio boletín:
- No sustituye al parche. Reduce la exposición; la corrección completa es el kernel nuevo.
- Puede afectar cargas de trabajo. El tráfico normal no debería notarlo, porque las opciones TCP de siempre viajan en el encabezado TCP, no en el de IP. Aun así, pruébala primero en un equipo que no sea producción.
- Quítala después de parchar:
sudo nft delete table inet cve_2026_98432.
Una regla aplicada a mano con nft no sobrevive un reinicio si no la agregas a la configuración persistente; si el servidor usa firewalld o ufw, que quien lo administra la traduzca a esa herramienta.
Lo otro que sí funciona hoy: cerrar puertos. Una base de datos o un ERP que solo usa la oficina no tiene por qué contestar a todo internet: restringir por IP o meterlo detrás de la VPN baja el riesgo de esta falla y de la siguiente.
Y el plazo de Fragnesia vence hoy
La otra falla del kernel de esta semana sí está en ataques reales. Fragnesia (CVE-2026-46300) entró al catálogo de vulnerabilidades explotadas (KEV) de la CISA el 28 de octubre con plazo al 31 de octubre, hoy. Es una escalada de privilegios local: necesita que el atacante ya esté dentro. El problema es cómo entra: según la CISA, se encadena con CVE-2026-109618 y CVE-2026-109619, las fallas de PHP de la ola PHP2Shell, para implantar webshells y ejecutar comandos como root. La CISA además pide revisión forense de los equipos afectados.
A diferencia de CVE-2026-98432, Fragnesia ya tiene parche: Ubuntu la corrigió en 22.04 (5.15.0-181.191), 24.04 (6.8.0-124.124) y 26.04 (7.0.0-22.22); Debian en sus tres versiones con soporte, y Red Hat dice haber liberado correcciones para todos sus productos afectados. Si tu servidor no se ha reiniciado con kernel nuevo desde mayo, cuando se publicó, tienes dos pendientes y no uno. Si no puedes reiniciar, la mitigación de Red Hat es bloquear los módulos esp4 y esp6 (rompe IPsec en ese equipo) o desactivar los espacios de nombres de usuario sin privilegios.
apt upgrade o dnf update descarga el kernel corregido, pero el servidor sigue corriendo el viejo hasta que se reinicia. Revisa con uname -r qué versión está activa de verdad. Es el error más común en las auditorías: el parche "instalado" desde hace meses y el equipo sin reiniciar desde hace un año.Qué hacer este fin de semana
- Inventario. Lista tus servidores Linux, sus distribuciones y si están expuestos a internet. Incluye la nube y los equipos que "nadie toca".
- Debian: actualiza el kernel y reinicia ya.
- Ubuntu y RHEL: aplica la regla de nftables (probada) en los equipos expuestos y suscríbete a los avisos de tu distribución para actualizar en cuanto salga el kernel.
- Fragnesia: confirma con
uname -rque corres un kernel posterior al parche; si no, programa el reinicio hoy. - PHP: si tienes sitios en PHP, verifica que ya estén en versiones corregidas de PHP2Shell; ese es el primer eslabón de la cadena.
- Cierra lo que no deba estar abierto y repasa la guía de hardening de servidores Linux.
No es un caso aislado. En septiembre ya contamos tres fallas del kernel que entraron al catálogo de explotadas, y esta misma semana la CISA metió al KEV la falla de la VPN de Cisco ASA y la de GitLab.
Fuentes: boletín RHSB-2026-016 y ficha CVE-2026-98432 de Red Hat (30-oct-2026); ficha CVE-2026-98432 y CVE-2026-46300 de Ubuntu (actualizadas 29 y 30-oct-2026); BleepingComputer (30-oct-2026); catálogo KEV de la CISA (entrada CVE-2026-46300); boletín RHSB-2026-003 de Red Hat; Debian Security Tracker.
Servidores Linux
Tus servidores mitigados antes del lunes
Revisamos qué servidores Linux tienes expuestos, aplicamos la mitigación de Red Hat donde haga falta, confirmamos el kernel activo y dejamos el reinicio programado para cuando salga el parche.



