Vulnerabilidade crítica no kernel do Linux CVE-2026-98432: Como verificar e atualizar seu VPS

Em outubro de 2026, uma vulnerabilidade crítica, CVE-2026-98432 , foi descoberta no kernel do Linux, classificada com 9.8 de 10 na escala CVSS. Ela afeta a forma como as conexões TCP IPv4 de entrada são tratadas e, sob certas condições, permite que um invasor obtenha acesso root a um servidor remotamente — sem senha e sem necessidade de ação por parte do administrador.

A seguir, você encontrará informações sobre quem será afetado, como verificar seu servidor e como protegê-lo. Todos os comandos devem ser executados como root ou com privilégios de administrador. sudo.

A vulnerabilidade em resumo

• O que é: Uma falha de segurança do tipo "use-after-free" no código que estabelece conexões TCP IPv4, causada por uma condição de corrida. O atacante envia pacotes especialmente criados para qualquer porta TCP aberta.
• Grãos afetados: todas as versões desde o Linux 4.4, o que significa praticamente todas as distribuições atuais.
• IPv6 não é afetado pelo bug principal.
• Quão real é a ameaça: Pesquisadores da Anthropic demonstraram uma cadeia de exploração funcional que obteve acesso root em um servidor com Multipath TCP (MPTCP) habilitado em cerca de 53 minutos. O código de exploração não foi divulgado.
• Ataques na natureza: Até 1º de novembro de 2026, nenhuma exploração foi relatada. Isso é motivo para atualizar com calma, não para adiar.

Os serviços Go apresentam um risco à parte. Desde o Go 1.24, os programas de servidor no Linux escutam em portas via MPTCP por padrão, sempre que o kernel o permite. Um administrador pode nem saber que seu servidor aceita tais conexões. Entre os programas populares, o Xray funciona dessa maneira — seus desenvolvedores já lançaram uma versão de emergência, v26.10.31, que desabilita o MPTCP por padrão.

Cada VPS executa seu próprio kernel, portanto, você precisa atualizar o kernel do seu servidor por conta própria. Nós atualizamos os nós de virtualização internamente.

Existe alguma solução para o seu sistema?

Situação em 1º de novembro de 2026. Correções estão sendo implementadas quase diariamente — confira os links no final deste artigo para obter informações atualizadas.

Passo 1. Verifique qual kernel você está executando.

Descubra a versão do kernel em execução:

uname -r

O número da versão por si só não diz nada: as distribuições incorporam correções em seus próprios kernels sem alterar a versão base. É mais confiável verificar o changelog do pacote do kernel — se ele mencionar o número CVE, a correção já está instalada.

Debian e Ubuntu:

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

No Debian, o uname -v O comando também mostra a versão completa do pacote do kernel em execução: compare-a com a tabela acima.

AlmaLinux, Rocky Linux, RHEL, Oracle Linux:

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

Se o comando não imprimir nada, o kernel em execução está vulnerável.

Em seguida, verifique quais serviços aceitam conexões via MPTCP. Servidores como esses foram o alvo do ataque demonstrado:

ss -lnMp

Uma saída vazia significa que não há ouvintes MPTCP.

Passo 2. Instale o kernel corrigido.

Faça um backup ou um snapshot do seu servidor antes de atualizar o kernel.

Debian 12 e 13

Os kernels corrigidos estão no repositório de segurança. Certifique-se de que ele esteja habilitado:

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

Se nada for encontrado, adicione o security.debian.org repositório para sua versão. Em seguida, atualize o sistema:

apt update
apt full-upgrade
reboot

Ubuntu

Os kernels corrigidos ainda não foram lançados. Verifique se há atualizações:

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

Se o seu servidor estiver conectado ao Ubuntu Pro, você pode verificar o plano de correção:

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

Assim que a correção for lançada, instale-a e reinicie o computador:

apt update
apt full-upgrade
reboot

Até lá, certifique-se de aplicar a proteção temporária da Etapa 3.

AlmaLinux 8, 9, 10

Os kernels corrigidos estão disponíveis atualmente apenas no repositório de testes. Instale-os se você se sentir confortável em fazê-lo em um servidor de produção e certifique-se de criar um snapshot antes de atualizar:

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

Após reiniciar, compare uname -r com as versões na tabela acima. Se preferir não instalar pacotes de teste, aplique a proteção temporária e aguarde até que a correção chegue ao repositório principal.

Rocky Linux e outros sistemas baseados em RHEL

Ainda não há solução. Você pode acompanhar as novidades com:

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

Assim que a correção for lançada:

dnf update kernel
reboot

Após a atualização: é necessário reiniciar o computador.

O novo kernel só entra em vigor após uma reinicialização. Para verificar se é necessário reiniciar o sistema:

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

# AlmaLinux, Rocky, RHEL
needs-restarting -r

Após reiniciar, repita a verificação da Etapa 1.

Etapa 3. Proteção temporária até que um kernel corrigido esteja disponível.

Essas medidas reduzem o risco, mas não substituem uma atualização do kernel.

Bloquear pacotes de gatilho

O ataque utiliza pacotes TCP com opções IP no cabeçalho IPv4. Esses pacotes praticamente nunca aparecem no tráfego normal, e a RFC 7126 já recomenda o descarte deles. A regra do nftables abaixo descarta todos os pacotes TCP IPv4 recebidos com opções e não afeta IPv6, UDP ou ICMP. Ela funciona em conjunto com o ufw e o firewalld.

Instale o nftables caso ainda não esteja instalado:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Crie o arquivo 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 seja restaurada após cada reinicialização, crie um serviço 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

Verifique se a regra foi carregada:

nft list table ip cve_2026_98432

Se você reiniciar o serviço nftables com um comando global flush ruleset regra, executar systemctl restart cve-2026-98432 depois.

Importante: não aplique esta regra em redes que utilizam rótulos CIPSO (SELinux ou Smack NetLabel) — as opções IP são usadas normalmente nesses casos. Se o seu servidor rotear tráfego para outras máquinas, a regra também descartará os pacotes TCP com opções IP dessas máquinas.

Desative o MPTCP se não precisar dele.

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

Essa configuração apenas impede new impedir a criação de sockets MPTCP. Os serviços já em execução continuarão a escutar via MPTCP, portanto, reinicie todos os serviços listados por ss -lnMp e certifique-se de que sua saída esteja agora vazia.

No AlmaLinux, o MPTCP está desativado por padrão, a menos que você o ative manualmente.

Desativar MPTCP em programas Go

Para serviços criados com Go 1.24 ou posterior, você pode desativar o MPTCP com uma variável de ambiente. Por exemplo, para um serviço chamado myservice:

systemctl edit myservice

Adicione o seguinte ao arquivo que será aberto:

[Service]
Environment=GODEBUG=multipathtcp=0

Em seguida, reinicie o serviço:

systemctl restart myservice

Atualização de raio-X

Se o seu servidor estiver executando o Xray, atualize-o para a versão 26.10.31 ou posterior. A versão anterior, 26.10.29, foi retirada pelos desenvolvedores. Esta atualização desativa o MPTCP, mas não corrige o kernel, portanto, uma atualização do kernel ainda é necessária.

Verifique mais uma configuração.

Uma segunda via de exploração, mais restrita, exige que a migração de requisições esteja habilitada. Ela está desabilitada por padrão — certifique-se disso:

sysctl net.ipv4.tcp_migrate_req

O comando deve imprimir 0.

Restringir o acesso aos seus serviços

Feche todas as portas do firewall que não precisam estar acessíveis pela internet. Sempre que possível, abra os serviços administrativos — SSH, painéis de controle, bancos de dados — somente para endereços IP confiáveis.

Passo 4. Após instalar o kernel corrigido

1. Reinicie o servidor e use os comandos da Etapa 1 para confirmar se o kernel corrigido está em execução.
2. Você pode remover a regra temporária:
   

   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 precisar do MPTCP, restaure a configuração: exclua /etc/sysctl.d/99-disable-mptcp.conf e corra sysctl -w net.mptcp.enabled=1.

Se algo der errado

Se o seu servidor não inicializar após a atualização do kernel, conecte-se através do console VNC no painel de controle e selecione o kernel anterior no menu de inicialização. Se você não tiver certeza de que consegue fazer isso sozinho ou precisar de ajuda com a atualização, entre em contato com nossa equipe de suporte.