Vulnerabilidade crítica do kernel de Linux CVE-2026-98432: Como comprobar e actualizar o seu VPS

En outubro de 2026, atopouse unha vulnerabilidade crítica, CVE-2026-98432 , no kernel de Linux, cunha cualificación de 9.8 sobre 10 na escala CVSS. Afecta á forma en que se xestionan as conexións TCP IPv4 entrantes e, en determinadas condicións, permite que un atacante obteña acceso root a un servidor de forma remota, sen contrasinal nin ningunha acción requirida por parte do administrador.

A continuación indícase quen está afectado, como comprobar o servidor e como protexelo. Todos os comandos execútanse como root ou con sudo.

A vulnerabilidade en resumo

• Que é: Un erro de tipo "use-after-free" no código que configura as conexións TCP IPv4, causado por unha condición de carreira. O atacante envía paquetes especialmente deseñados a calquera porto TCP aberto.
• Granos afectados: todas as versións desde Linux 4.4, o que significa practicamente todas as distribucións actuais.
• IPv6 non se ve afectado polo erro principal.
• Canto real é a ameaza: Investigadores de Anthropic demostraron unha cadea de exploits funcional que obtivo acceso root nun servidor con Multipath TCP (MPTCP) activado en aproximadamente 53 minutos. O código do exploit non foi publicado.
• Ataques na natureza: A 1 de novembro de 2026 non se informou de ningunha explotación. Esa é unha razón para actualizar con calma, non para pospoñela.

Os servizos de Go corren un risco separado. Desde a versión 1.24 de Go, os programas de servidor en Linux escoitan os portos a través de MPTCP por defecto sempre que o kernel o permite. Un administrador pode nin sequera saber que o seu servidor acepta tales conexións. Entre os programas populares, Xray funciona deste xeito: os seus desenvolvedores xa lanzaron unha versión de emerxencia, a v26.10.31, que desactiva MPTCP por defecto.

Cada VPS executa o seu propio kernel, polo que debes actualizar o kernel dentro do teu servidor ti mesmo. Nós actualizamos os nodos de virtualización nós mesmos.

Hai algunha solución para o teu sistema?

Estado a 1 de novembro de 2026. As correccións están a chegar case a diario; consulta as ligazóns ao final deste artigo para coñecer o estado actual.

Paso 1. Comproba que núcleo estás a executar

Atopar a versión do kernel en execución:

uname -r

O número de versión por si só non indica nada: as distribucións retroportan as correccións aos seus propios núcleos sen modificar a versión base. É máis fiable consultar o rexistro de cambios do paquete do núcleo; se menciona o número CVE, a corrección xa está instalada.

Debian e Ubuntu:

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

En Debian, o uname -v O comando tamén mostra a versión completa do paquete do kernel en execución: compáraa coa táboa anterior.

AlmaLinux, Rocky Linux, RHEL e Oracle Linux:

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

Se o comando non imprime nada, o kernel en execución é vulnerable.

A continuación, comproba que servizos aceptan conexións a través de MPTCP. Servidores como estes foron o obxectivo do ataque demostrado:

ss -lnMp

Unha saída baleira significa que non hai escoitadores MPTCP.

Paso 2. Instalar o kernel fixo

Fai unha copia de seguridade ou unha instantánea do teu servidor antes de actualizar o kernel.

Debian 12 e 13

Os núcleos arranxados están no repositorio de seguridade. Asegúrate de que estea activado:

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

Se non atopa nada, engade o security.debian.org repositorio para a túa versión. Despois actualiza o sistema:

apt update
apt full-upgrade
reboot

Ubuntu

Os núcleos corrixidos aínda non foron publicados. Busca actualizacións:

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

Se o teu servidor está conectado a Ubuntu Pro, podes consultar o plan de correccións:

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

Unha vez publicada a corrección, instálaa e reinicia:

apt update
apt full-upgrade
reboot

Ata entón, asegúrate de aplicar a protección temporal do Paso 3.

AlmaLinux 8, 9, 10

Os núcleos corrixidos só están dispoñibles actualmente no repositorio de probas. Instálaos se che resulta cómodo facelo nun servidor de produción e asegúrate de facer unha instantánea antes de actualizar:

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

Despois de reiniciar, comparar uname -r coas versións da táboa anterior. Se prefire non instalar os paquetes de proba, aplique a protección temporal e agarde a que a corrección chegue ao repositorio principal.

Rocky Linux e outros sistemas baseados en RHEL

Aínda non hai ningunha solución. Podes comprobalo con:

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

Unha vez publicada a corrección:

dnf update kernel
reboot

Despois da actualización: é necesario reiniciar

O novo núcleo só ten efecto despois dun reinicio. Para comprobar se é necesario:

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

# AlmaLinux, Rocky, RHEL
needs-restarting -r

Despois de reiniciar, repita a comprobación desde o paso 1.

Paso 3. Protección temporal ata que estea dispoñible un kernel fixo

Estas medidas reducen o risco pero non substitúen unha actualización do kernel.

Bloquear os paquetes desencadeantes

O ataque emprega paquetes TCP con opcións IP na cabeceira IPv4. Practicamente nunca aparecen no tráfico normal e a RFC 7126 xa recomenda descartalos. A regra nftables que aparece a continuación descarta todos os paquetes TCP IPv4 entrantes con opcións e non afecta a IPv6, UDP nin ICMP. Funciona xunto con ufw e firewalld.

Instala nftables se aínda non está instalado:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Crea o ficheiro de regras:

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 a regra se restaure despois de cada reinicio, cree un servizo 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

Comproba que a regra estea cargada:

nft list table ip cve_2026_98432

Se reinicias o servizo nftables cunha configuración global flush ruleset gobernar, correr systemctl restart cve-2026-98432 despois.

Importante: non apliques esta regra en redes que usen etiquetas CIPSO (SELinux ou Smack NetLabel); alí úsanse normalmente as opcións IP. Se o teu servidor enruta o tráfico para outras máquinas, a regra tamén descartará os seus paquetes TCP con opcións IP.

Desactiva MPTCP se non o necesitas

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

Esta configuración só impide novo que se creen sockets MPTCP. Os servizos que xa estean en execución seguirán escoitando a través de MPTCP, polo que reinicie todos os servizos listados por ss -lnMp e asegúrate de que a súa saída agora estea baleira.

En AlmaLinux, MPTCP está desactivado por defecto a non ser que o actives ti mesmo.

Desactivar MPTCP nos programas Go

Para os servizos creados con Go 1.24 ou posterior, podes desactivar MPTCP cunha variable de ambiente. Por exemplo, para un servizo chamado myservice:

systemctl edit myservice

Engade o seguinte ao ficheiro que se abre:

[Service]
Environment=GODEBUG=multipathtcp=0

Despois reinicie o servizo:

systemctl restart myservice

Actualizar a radiografía

Se o teu servidor executa Xray, actualízao á versión 26.10.31 ou posterior. Os desenvolvedores retiraron a versión anterior, a 26.10.29. Esta actualización desactiva MPTCP pero non arranxa o kernel, polo que aínda é necesaria unha actualización do kernel.

Marca unha configuración máis

Unha segunda ruta de explotación, máis estreita, require que a migración de solicitudes estea activada. Está desactivada por defecto; asegúrate diso:

sysctl net.ipv4.tcp_migrate_req

O comando debería imprimir 0.

Restrinxir o acceso aos teus servizos

Pecha todos os portos do cortafuegos que non precisen ser accesibles desde Internet. Sempre que sexa posible, abre os servizos administrativos (SSH, paneis de control, bases de datos) só en enderezos IP de confianza.

Paso 4. Despois de instalar o núcleo arranxado

1. Reinicie o servidor e use os comandos do Paso 1 para confirmar que o kernel arranxado está a executarse.
2. Podes eliminar a regra 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. Se precisa MPTCP, restaure a configuración: eliminar /etc/sysctl.d/99-disable-mptcp.conf e correr sysctl -w net.mptcp.enabled=1.

Se algo sae mal

Se o teu servidor non arranca despois da actualización do kernel, conéctate a través da consola VNC no panel de control e selecciona o kernel anterior no menú de arranque. Se non estás seguro de que podes facelo ti mesmo ou necesitas axuda coa actualización, ponte en contacto co noso equipo de soporte.