Vulnerabilidad crítica del kernel de Linux CVE-2026-98432: Cómo comprobar y actualizar su VPS

En octubre de 2026, se descubrió una vulnerabilidad crítica, CVE-2026-98432 , en el kernel de Linux, con una calificación de 9.8 sobre 10 en la escala CVSS. Esta vulnerabilidad afecta la forma en que se gestionan las conexiones TCP IPv4 entrantes y, bajo ciertas condiciones, permite a un atacante obtener acceso de administrador a un servidor de forma remota, sin contraseña y sin que el administrador tenga que realizar ninguna acción.

A continuación se indica quiénes se ven afectados, cómo comprobar su servidor y cómo protegerlo. Todos los comandos se ejecutan como root o con sudo.

La vulnerabilidad en resumen

• Qué es: Un error de uso de memoria liberada en el código que establece las conexiones TCP IPv4, causado por una condición de carrera. El atacante envía paquetes especialmente diseñados a cualquier puerto TCP abierto.
• Núcleos afectados: Todas las versiones desde Linux 4.4, lo que significa prácticamente todas las distribuciones actuales.
• IPv6 no se ve afectado por el error principal.
• ¿Qué tan real es la amenaza? Investigadores de Anthropic demostraron una cadena de exploits funcional que logró obtener acceso de administrador en un servidor con Multipath TCP (MPTCP) habilitado en aproximadamente 53 minutos. El código del exploit no ha sido publicado.
• Ataques en estado salvaje: Al 1 de noviembre de 2026, no se ha reportado ninguna explotación. Esto es motivo para actualizar con tranquilidad, no para posponerlo.

Los servicios de Go conllevan un riesgo adicional. Desde Go 1.24, los programas de servidor en Linux escuchan en los puertos mediante MPTCP de forma predeterminada siempre que el kernel lo permita. Un administrador podría incluso desconocer que su servidor acepta este tipo de conexiones. Entre los programas más populares, Xray funciona de esta manera; sus desarrolladores ya han lanzado una versión de emergencia, la v26.10.31, que desactiva MPTCP de forma predeterminada.

Cada VPS ejecuta su propio kernel, por lo que deberá actualizar el kernel de su servidor manualmente. Nosotros actualizamos los nodos de virtualización.

¿Existe alguna solución para su sistema?

Estado al 1 de noviembre de 2026. Se están implementando correcciones casi a diario; consulte los enlaces al final de este artículo para conocer el estado actual.

Paso 1. Compruebe qué kernel está ejecutando.

Averigüe la versión del kernel en ejecución:

uname -r

El número de versión por sí solo no aporta información útil: las distribuciones incorporan las correcciones a sus propios núcleos sin modificar la versión base. Es más fiable consultar el registro de cambios del paquete del núcleo: si menciona el número CVE, la corrección ya está instalada.

Debian y Ubuntu:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432

En Debian, el uname -v El comando también muestra la versión completa del paquete del kernel en ejecución: compárela con la tabla anterior.

AlmaLinux, Rocky Linux, RHEL, Oracle Linux:

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

Si el comando no imprime nada, el núcleo en ejecución es vulnerable.

A continuación, compruebe qué servicios aceptan conexiones a través de MPTCP. Servidores como estos fueron el objetivo del ataque demostrado:

ss -lnMp

Una salida vacía significa que no hay oyentes MPTCP.

Paso 2. Instale el kernel corregido.

Realice una copia de seguridad o una instantánea de su servidor antes de actualizar el kernel.

Debian 12 y 13

Los kernels corregidos se encuentran en el repositorio de seguridad. Asegúrese de que esté habilitado:

grep -r security.debian.org /etc/apt/sources.list /etc/apt/sources.list.d/

Si no se encuentra nada, agregue el security.debian.org repositorio para su versión. Luego actualice el sistema:

apt update
apt full-upgrade
reboot

Ubuntu

Todavía no se han publicado versiones corregidas del kernel. Compruebe si hay actualizaciones:

apt update
apt list --upgradable | grep linux-image

Si su servidor está conectado a Ubuntu Pro, puede consultar el plan de solución:

pro fix CVE-2026-98432 --dry-run

Una vez que se publique la solución, instálela y reinicie el sistema:

apt update
apt full-upgrade
reboot

Hasta entonces, asegúrese de aplicar la protección temporal del paso 3.

AlmaLinux 8, 9, 10

Actualmente, los kernels corregidos solo están disponibles en el repositorio de pruebas. Instálelos si se siente cómodo haciéndolo en un servidor de producción y asegúrese de crear una instantánea antes de actualizar.

dnf install -y almalinux-release-testing
dnf update 'kernel*' --enablerepo=almalinux-testing
dnf config-manager --disable almalinux-testing
reboot

Después de reiniciar, compare uname -r con las versiones que aparecen en la tabla anterior. Si prefiere no instalar los paquetes de prueba, aplique la protección temporal y espere a que la corrección llegue al repositorio principal.

Rocky Linux y otros sistemas basados ​​en RHEL

Todavía no hay solución. Puedes estar atento a ella con:

dnf --refresh updateinfo info --all --cves CVE-2026-98432

Una vez que se publique la solución:

dnf update kernel
reboot

Tras la actualización: es necesario reiniciar el equipo.

El nuevo kernel solo surte efecto después de reiniciar el sistema. Para comprobar si es necesario reiniciar:

# Debian and Ubuntu
[ -f /var/run/reboot-required ] && echo "Reboot required"

# AlmaLinux, Rocky, RHEL
needs-restarting -r

Tras reiniciar el sistema, repita la comprobación del paso 1.

Paso 3. Protección temporal hasta que haya un kernel corregido disponible.

Estas medidas reducen el riesgo, pero no sustituyen una actualización del kernel.

Bloquear los paquetes de activación

El ataque utiliza paquetes TCP con opciones IP en la cabecera IPv4. Estos paquetes prácticamente nunca aparecen en el tráfico normal, y la RFC 7126 ya recomienda descartarlos. La regla de nftables que se muestra a continuación descarta todos los paquetes TCP IPv4 entrantes con opciones y no afecta a IPv6, UDP ni ICMP. Funciona junto con ufw y firewalld.

Instala nftables si aún no está instalado:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Cree el archivo de reglas:

cat > /etc/cve-2026-98432.nft <<'EOF'
table ip cve_2026_98432 {
    chain pre {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength gt 5 counter drop
    }
}
EOF

Para que la regla se restablezca después de cada reinicio, cree un servicio systemd:

cat > /etc/systemd/system/cve-2026-98432.service <<'EOF'
[Unit]
Description=Mitigation for CVE-2026-98432
After=network-pre.target nftables.service firewalld.service ufw.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/nft delete table ip cve_2026_98432
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now cve-2026-98432.service

Compruebe que la regla esté cargada:

nft list table ip cve_2026_98432

Si reinicia el servicio nftables con una variable global flush ruleset regla, correr systemctl restart cve-2026-98432 después.

Importante: no aplique esta regla en redes que utilicen etiquetas CIPSO (SELinux o Smack NetLabel), ya que allí se utilizan normalmente opciones IP. Si su servidor enruta el tráfico de otras máquinas, la regla también descartará sus paquetes TCP con opciones IP.

Desactive MPTCP si no lo necesita.

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

Esta configuración solo impide ¡nuevos Socios! de Los sockets MPTCP no se crean. Los servicios que ya se están ejecutando seguirán escuchando a través de MPTCP, así que reinicie todos los servicios que aparecen en la lista. ss -lnMp y asegúrese de que su salida ahora esté vacía.

En AlmaLinux, MPTCP está deshabilitado por defecto a menos que lo habilites tú mismo.

Deshabilitar MPTCP en programas Go

Para los servicios creados con Go 1.24 o posterior, puede deshabilitar MPTCP con una variable de entorno. Por ejemplo, para un servicio llamado myservice:

systemctl edit myservice

Agregue lo siguiente al archivo que se abre:

[Service]
Environment=GODEBUG=multipathtcp=0

A continuación, reinicie el servicio:

systemctl restart myservice

Actualización de rayos X

Si su servidor utiliza Xray, actualícelo a la versión 26.10.31 o posterior. La versión anterior, la 26.10.29, ha sido retirada por sus desarrolladores. Esta actualización desactiva MPTCP, pero no soluciona el problema del kernel, por lo que aún se requiere una actualización del kernel.

Comprobar una configuración más

Una segunda vía de explotación, más restringida, requiere que la migración de solicitudes esté habilitada. Está desactivada por defecto; asegúrese de ello.

sysctl net.ipv4.tcp_migrate_req

El comando debería imprimir 0.

Restringir el acceso a sus servicios

Cierre todos los puertos del cortafuegos que no necesiten ser accesibles desde internet. Siempre que sea posible, abra los servicios administrativos (SSH, paneles de control, bases de datos) solo a direcciones IP de confianza.

Paso 4. Después de instalar el kernel corregido

1. Reinicie el servidor y utilice los comandos del paso 1 para confirmar que el kernel corregido se está ejecutando.
2. Puedes eliminar la regla temporal:
   

   systemctl disable --now cve-2026-98432.service
   rm /etc/systemd/system/cve-2026-98432.service /etc/cve-2026-98432.nft
   systemctl daemon-reload

   
   
3. Si necesita MPTCP, restaure la configuración: eliminar /etc/sysctl.d/99-disable-mptcp.conf y correr sysctl -w net.mptcp.enabled=1.

Si algo va mal

Si su servidor no arranca tras la actualización del kernel, conéctese mediante la consola VNC en el panel de control y seleccione el kernel anterior en el menú de arranque. Si no está seguro de poder hacerlo usted mismo o necesita ayuda con la actualización, póngase en contacto con nuestro equipo de soporte.