CVE-2026-98432: falha TCP no kernel Linux abre caminho a root remoto em servidores MPTCP

Uma vulnerabilidade crítica do tipo use-after-free na pilha TCP IPv4 do kernel Linux, registada como CVE-2026-98432, pode ser transformada em execução remota de código como root, sem autenticação, em servidores que aceitam ligações Multipath TCP (MPTCP). Já foi demonstrado um exploit funcional, e as correções estão a chegar de forma desigual às principais distribuições.

O que aconteceu

O erro é uma condição de corrida na forma como o kernel processa os pedidos de ligação TCP. Quando uma ligação passa de pedido pendente a socket completo, o kernel entrega o buffer de opções IP ao novo socket sem guardar uma cópia própria. Se, nesse mesmo instante, outro núcleo de CPU estiver a tratar um SYN retransmitido para o mesmo pedido, esse outro caminho de código pode continuar a ler memória que já mudou de dono — um use-after-free clássico. Existe uma janela semelhante durante a migração de sockets de pedido, quando net.ipv4.tcp_migrate_req está ativo ou é usado um programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.

Factos essenciais:

Afetados: kernels Linux a partir da versão 4.4, incluindo as versões do Ubuntu, Red Hat Enterprise Linux e Rocky Linux.
Gravidade: 9,8/10 na avaliação da equipa CVE do kernel Linux. A Red Hat atribui-lhe uma pontuação mais baixa, de 5,9, tratando-a sobretudo como risco de falha do kernel (negação de serviço), porque vencer a corrida é difícil.
RCE comprovado: um exploit de demonstração — produzido por um modelo de IA ainda não lançado — contornou a aleatorização do espaço de endereços do kernel (KASLR) e executou comandos arbitrários como root num servidor com um listener MPTCP, em condições específicas, em cerca de 53 minutos.
O TCP convencional também é afetado, embora a execução remota de código não tenha sido demonstrada publicamente em servidores sem listener MPTCP.
Sem exploração confirmada no terreno à data desta publicação.
Não afetados: macOS (kernel diferente) e RHEL 7 (o código vulnerável não está presente).

Porque é importante

O MPTCP permite que uma única ligação use vários caminhos de rede em simultâneo — por exemplo, Wi-Fi e dados móveis — e normalmente está desligado, a menos que a aplicação o peça. O problema: desde o Go 1.24, os listeners TCP em Linux ativam o MPTCP por omissão sempre que o kernel o suporta. Qualquer serviço escrito em Go pode, portanto, estar a expor um listener MPTCP sem que os administradores alguma vez o tenham ativado.

A diferença entre as duas pontuações também merece atenção. Uma corrida difícil de vencer não é impossível de vencer, e uma demonstração pública que transforma um «bug que provoca falhas» em root remoto em menos de uma hora mostra a rapidez com que os prazos de exploração estão a encurtar — sobretudo à medida que o desenvolvimento de exploits assistido por IA amadurece.

Estado das correções (a 30 de outubro de 2026)

Kernel upstream: corrigido e portado para os ramos estáveis mantidos.
Debian: corrigido no kernel 6.1.190-1 (Debian 12 «Bookworm») e 6.12.113-1 (Debian 13 «Trixie»); testing e unstable também estão corrigidas.
Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS e 26.10 continuam vulneráveis, com correções do kernel em curso.
RHEL 8, 9, 10 / Rocky Linux 8, 9, 10: afetados; as correções estão previstas para próximas atualizações.
Oracle Linux, Amazon Linux, SUSE: correções disponíveis para algumas versões do kernel.

O que fazer

Primeiro, corrigir. Acompanhe os avisos de segurança da sua distribuição e instale os pacotes de kernel atualizados assim que estiverem disponíveis — depois reinicie ou confirme que o live-patching cobre este CVE.
Identifique a sua exposição ao MPTCP. Execute ss -Mtln para listar os listeners MPTCP e verifique sysctl net.mptcp.enabled. Dê especial atenção aos serviços compilados com Go 1.24 ou superior.
Não confie apenas na desativação do MPTCP. A falha de fundo continua acessível através de TCP convencional; desligar o MPTCP reduz a via de RCE demonstrada, mas não elimina o erro.
Filtre onde ainda não puder corrigir. Restrinja os serviços expostos a redes ou intervalos IP de confiança. Como medida temporária, descarte na firewall do host ou do perímetro (por exemplo, com nftables) os pacotes TCP IPv4 de entrada que contenham opções IP — o tráfego legítimo quase nunca as usa. Teste antes de aplicar de forma generalizada.
Reveja as definições de migração. Se não precisar, mantenha net.ipv4.tcp_migrate_req desativado e audite os programas BPF do tipo reuseport.
Esteja atento a falhas. Kernel panics ou mensagens «oops» inexplicáveis no código TCP de hosts expostos à internet merecem investigação, não apenas um reinício.

Saber quais dos seus hosts expostos à internet ainda correm um kernel vulnerável — e quais expõem discretamente serviços com que não contava — é precisamente o tipo de lacuna que o nosso serviço de análise de vulnerabilidades foi concebido para revelar, para que o esforço de correção vá para onde está a exposição real.