Fallo crítico en el kernel de Linux (CVE-2026-98432): qué servidores afecta y cómo mitigarlo mientras llega el parche

Publicado el 6 noviembre 2026 · Equipo mitza.es

Mucha de la infraestructura de las empresas funciona sobre Linux sin que nadie lo recuerde: el servidor web de la tienda online, la máquina virtual que aloja el programa de gestión, un contenedor en la nube o un equipo de red. El 30 de octubre de 2026 Red Hat publicó un boletín de seguridad sobre un fallo del kernel de Linux (el núcleo del sistema) que identifica como CVE-2026-98432 y que puntúa con un 9,8 sobre 10. Lo actualizó el 4 de noviembre. Este artículo resume lo que Red Hat ha confirmado a fecha de 6 de noviembre de 2026, sin ir más allá de lo que dicen sus avisos.

Qué dice Red Hat

• Identificador y gravedad: CVE-2026-98432, boletín RHSB-2026-016. Puntuación CVSS 3.1 de 9,8 con vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, es decir: se ataca por red, de forma sencilla, sin privilegios y sin intervención de ningún usuario. Red Hat y el registro de CVE coinciden en la cifra. Para los productos de Red Hat la severidad es crítica.
• Qué falla: una condición de carrera en el tratamiento de la red TCP. Cuando el sistema procesa de forma simultánea peticiones de conexión retransmitidas o migraciones de sockets, las opciones del socket pueden liberarse de la memoria mientras otra parte del sistema aún las está usando. En lenguaje llano: el kernel «tira» un dato que todavía necesita, y un atacante podría aprovechar ese hueco.
• Qué necesita el atacante: enviar a un sistema que acepte conexiones TCP por IPv4 paquetes con opciones IP y acertar con el momento de dos operaciones concurrentes. Es un ataque remoto y sin autenticación, pero requiere temporización precisa.
• Qué consecuencias: Red Hat menciona denegación de servicio, corrupción de memoria y ejecución remota de código. La ejecución fiable de código exige un control preciso de la memoria, así que lo más difícil de conseguir es esto último; el aviso del boletín sí lo señala como posible.
• Fechas: publicado el 30 de octubre de 2026 y actualizado el 4 de noviembre.

Qué sistemas están afectados

Red Hat indica como afectados directamente Red Hat Enterprise Linux 8, 9 y 10 y Red Hat OpenShift Container Platform 4 (los nodos con RHEL CoreOS). También pueden estar afectados los productos construidos sobre el kernel de RHEL, como Red Hat OpenStack Platform y Red Hat Virtualization. Los sistemas que aceptan conexiones TCP entrantes son los más expuestos. No es necesario que el protocolo MPTCP esté activo para que exista el riesgo.

Una cautela importante: Red Hat solo documenta sus propios productos y no indica números de versión del kernel original ni paquetes corregidos concretos («está acelerando la publicación de las correcciones»; el estado figura como «en curso»). No hemos podido confirmar el estado en otras distribuciones como Debian, Ubuntu, AlmaLinux o Rocky; consulta el aviso de seguridad de la tuya antes de dar el problema por descartado.

¿Se está explotando ya?

Ni el boletín ni la ficha de Red Hat dicen que el fallo se esté explotando, y no figura como explotado en la información que hemos revisado. Eso puede cambiar en cualquier momento, y un fallo que se ataca por red y sin credenciales es un candidato evidente. Conviene tratarlo como un parche prioritario, no como una tarea del próximo mantenimiento.

Qué hacer hoy: checklist

1. Haz inventario. Anota qué servidores, máquinas virtuales, contenedores y equipos de red de tu empresa funcionan con Linux, con qué distribución y quién los gestiona. Si los gestiona un proveedor o un hosting, pídele por escrito que confirme si te afecta y cuándo aplicará el parche.
2. Comprueba versión y distribución. En un servidor Linux, cat /etc/os-release te da la distribución y uname -r la versión del kernel.
3. Aplica la actualización del kernel en cuanto exista para tu distribución. Un kernel nuevo requiere reiniciar el sistema (salvo que uses parcheo en caliente), así que planifícalo. Red Hat dice que es la «única solución completa».
4. Mientras no haya parche, aplica la mitigación temporal. Red Hat propone descartar los paquetes TCP entrantes que lleven opciones IP, con una regla de nftables (ver más abajo).
5. Limita lo que está expuesto. Un servidor que solo necesita atenderte a ti no debería aceptar conexiones de todo internet. Revisa el cortafuegos: si quieres repasar cómo se organiza, mira nuestra guía de qué es un firewall y qué necesita una pyme.
6. Ten una copia reciente y probada antes de tocar nada: la regla 3-2-1 sigue siendo tu seguro.

La mitigación temporal de Red Hat

Red Hat propone una regla de nftables que descarta los paquetes TCP IPv4 con opciones IP. Se guarda en un archivo (por ejemplo, cve-2026-98432.nft) con este contenido:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Se comprueba con sudo nft --check --file cve-2026-98432.nft y se aplica con sudo nft --file cve-2026-98432.nft. Dos advertencias de Red Hat: la regla no persiste tras un reinicio, y no sustituye al parche. Una vez actualizado el kernel, se retira con sudo nft delete table inet cve_2026_98432. Prueba la regla antes en un entorno controlado y, si no estás seguro de lo que haces en un servidor de producción, deja que lo aplique tu administrador.

Lo que Red Hat desaconseja: desactivar MPTCP (net.mptcp.enabled=0) no es una mitigación completa y, de hecho, RHEL lo trae desactivado por defecto y sigue siendo vulnerable. Tampoco se puede usar ss -Mlnp como prueba de exposición. En OpenShift, el tráfico entre pods todavía no tiene mitigación; Red Hat remite a un artículo de soporte específico.

¿Y si no gestiono servidores?

Si tu web está en un hosting compartido o gestionado, este parche es responsabilidad del proveedor: lo razonable es preguntarle si ya lo ha aplicado. Si tienes un servidor virtual (VPS) o un servidor propio, sí te toca a ti o a quien lo administre. En cualquier caso, es una buena ocasión para fijar un plazo máximo de parcheo de fallos críticos y para revisar que tu proveedor te informa cuando algo así ocurre. Si estás valorando alojar tu infraestructura fuera de casa, esta guía sobre cloud computing para pymes te ayuda a decidir qué parte gestiona cada uno.

Preguntas rápidas

¿Me afecta si uso Windows?

No este fallo, que es del kernel de Linux. Si usas Windows, el calendario relevante es el de las actualizaciones mensuales; por ejemplo, en octubre hubo un Patch Tuesday con más de 1.400 vulnerabilidades.

¿Qué significa «9,8» y es lo máximo?

La escala CVSS llega a 10. Un 9,8 indica un riesgo muy alto: acceso por red, sin credenciales y con impacto total sobre confidencialidad, integridad y disponibilidad. La gravedad real también depende de si el sistema está expuesto y de lo difícil que sea explotarlo, algo que aquí exige temporización precisa.

¿Tiene relación con la normativa NIS2?

La gestión de vulnerabilidades y de proveedores forma parte de las medidas que se esperan de las empresas incluidas. Tienes el contexto en nuestra guía de la normativa NIS2 para pymes.

Cómo te ayudamos en Mitza

Revisamos qué servidores y equipos tienes expuestos, comprobamos versiones, aplicamos parches y mitigaciones y dejamos documentado el proceso. Descubre cómo planteamos el mantenimiento informático para pymes o cuéntanos tu caso desde la página de contacto.

Lectura relacionada: OpenSSH 10.6p2 y el fallo de contraseñas largas en Alpine Linux y ransomware en empresas españolas.