A CVE-2026-98432 é uma falha na forma como o kernel do Linux aceita pedidos de conexão TCP. Ela permite que um atacante remoto, sem senha, derrube o servidor ou corrompa a memória do kernel. A equipe de CVE do kernel do Linux dá a ela nota 9,8 de 10, e a Anthropic afirma que seu modelo Claude escreveu um exploit que dá ao atacante acesso root em servidores que aceitam conexões MPTCP. A correção já está no kernel oficial e o Debian já a lançou, mas em 30 de outubro de 2026 o Ubuntu a lista como "work in progress" (em andamento) para 22.04, 24.04 e 26.04, e a Red Hat lista o RHEL 8, 9 e 10 como afetados e sem atualização. Até a atualização chegar: desative o MPTCP se não precisar dele, bloqueie pacotes IPv4 que trazem opções IP, restrinja quem consegue alcançar seus servidores e agende a reinicialização.

O que é a CVE-2026-98432 e por que ela importa para a sua empresa?

Segundo o registro oficial da CVE, a falha está no momento em que um handshake TCP sobre IPv4 se completa: o kernel entrega à nova conexão as opções IP guardadas com o pedido de conexão sem copiá-las, enquanto outra CPU pode, nesse mesmo instante, processar um pedido duplicado e montar uma resposta com essas opções. Se o kernel liberar essa memória antes, ele a lê depois de liberada, um erro conhecido como use-after-free. A falha existe desde o kernel 4.4. A equipe de CVE do kernel a publicou em 15 de outubro de 2026 e deu nota 9,8 de 10 porque ela pode ser alcançada pela rede, durante o handshake e antes de qualquer login, sem interação do usuário.

Em uma publicação de 27 de outubro, a Anthropic disse que o Claude escreveu um exploit que permite a um atacante remoto sem credenciais executar comandos como root em servidores Linux que aceitam conexões MPTCP, ou TCP multicaminho. No teste, o exploit levou 48 minutos para vazar um endereço da memória do kernel e depois 5 minutos para chegar à execução de comandos. Pior: uma tentativa que falha não derruba o servidor; só aquela conexão falha, então o atacante pode continuar tentando sem que ninguém perceba. A Anthropic não publicou o exploit em si.

A Red Hat descreve o impacto principal como queda do servidor e negação de serviço, com possível corrupção de memória. Na edição de 30 de outubro do catálogo de vulnerabilidades exploradas conhecidas da CISA, a falha ainda não tinha sido incluída.

A atualização já chegou à sua distribuição?

Este é o status mostrado na página oficial de cada distribuição em 30 de outubro de 2026:

DistribuiçãoStatus
Ubuntu 22.04, 24.04, 26.04 e 26.10Vulnerável, correção "work in progress" (em andamento); para o 24.04 no kernel 6.8.0-149 (página do Ubuntu)
Ubuntu 16.04, 18.04 e 20.04Vulnerável
Red Hat Enterprise Linux 8, 9 e 10Afetado, sem atualização lançada (página da Red Hat)
Red Hat Enterprise Linux 6 e 7Não afetado
Debian 12 e 13Corrigido em 6.1.190-1 e 6.12.113-1 (rastreador do Debian)

No kernel oficial, a correção saiu nas versões 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3. Mas a maioria dos servidores roda o kernel da sua distribuição, então o que vale é a página da sua distribuição, não o número de versão oficial.

Como saber se um servidor está exposto?

Rode estes comandos em cada servidor Linux que aceita conexões da internet:

uname -r
cat /proc/sys/net/mptcp/enabled
ss -Mln
cat /proc/sys/net/ipv4/tcp_migrate_req
  • O primeiro mostra a versão do kernel; compare com a página da sua distribuição. No Ubuntu 24.04, por exemplo, todas as versões disponíveis hoje estão sem correção.
  • Um valor 1 no segundo significa que o MPTCP está ativado, que é o padrão segundo a documentação do kernel.
  • O terceiro lista os serviços que aceitam conexões MPTCP. Qualquer serviço que aparecer é o tipo de alvo que a Anthropic explorou. Atenção aos programas em Go: segundo as notas de lançamento do Go 1.24, os listeners deles agora usam MPTCP por padrão onde ele é suportado.
  • O quarto deve mostrar 0; segundo o registro da CVE, o segundo caminho da falha só funciona quando o valor é 1.

A solução temporária até a atualização chegar: 5 passos

  1. Se a sua distribuição já tem a correção, instale agora e reinicie. No Debian 12 e 13, por exemplo: 
    sudo apt update && sudo apt upgrade
sudo reboot
    O novo kernel não protege você até o servidor estar rodando com ele.
  2. Desative o MPTCP se nenhum serviço precisar dele. Isso fecha o tipo de alvo que a Anthropic explorou: 
    sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
    O primeiro comando aplica a configuração na hora; o segundo a mantém depois de uma reinicialização. A documentação do kernel diz que a configuração vale por namespace de rede, então aplique também dentro dos contêineres. Programas em Go voltam automaticamente ao TCP comum quando o MPTCP não está disponível. Mas nem a Anthropic nem nenhuma distribuição diz que desativá-lo elimina a falha em si, então isso reduz o risco em vez de curá-lo.
  3. Bloqueie pacotes TCP que trazem opções de IPv4. O cenário de pontuação do registro da CVE pressupõe um atacante que envia um pedido de conexão com a opção Record Route ou Timestamp do IPv4, e o tráfego comum de web, e-mail e SSH não precisa dessas opções. Peça ao seu administrador de rede uma regra de firewall que descarte pacotes TCP de entrada cujo cabeçalho IPv4 tenha mais de 20 bytes, e teste primeiro em um servidor. Nenhuma distribuição diz que isso bloqueia a falha, mas remove a condição que a pontuação pressupõe.
  4. Restrinja quem consegue alcançar seus servidores. A falha precisa de uma porta TCP aberta que aceite conexões, então feche todas as portas de que você não precisa e deixe o SSH e os painéis de administração acessíveis só a partir de endereços IP específicos ou por VPN. Se o site fica atrás de um intermediário como uma CDN, deixe o servidor de origem aceitar conexões só dos endereços desse serviço.
  5. Prepare a atualização antes que ela chegue. Acompanhe as páginas do Ubuntu e da Red Hat sobre esta CVE, aprove antecipadamente a atualização do kernel e defina uma janela de reinicialização, para que a correção entre no mesmo dia em que for lançada. Fique de olho no log do kernel em busca de quedas que mencionem ip_options_build: 
    sudo journalctl -k | grep -i ip_options_build
    Mas um log tranquilo não significa segurança, porque uma tentativa que falha não derruba o servidor.

E se os seus servidores ficam com um provedor de hospedagem?

Na hospedagem compartilhada e nos serviços gerenciados, o kernel pertence ao provedor, não a você. Faça três perguntas: qual distribuição e qual versão de kernel os servidores dele usam, quando ele vai instalar a correção e o que está fazendo para reduzir o risco até lá. Um servidor virtual privado (VPS) normalmente deixa o kernel nas suas mãos, então aplique você mesmo os passos acima.

A visão da Origami

Como no nosso artigo sobre vulnerabilidades do PHP, quando a atualização oficial atrasa, são os passos temporários que protegem os servidores nos primeiros dias. Eles reduzem o risco, porém; a única cura é o kernel corrigido depois de uma reinicialização. Na Origami podemos verificar seus servidores Linux, aplicar os passos temporários sem interromper seus serviços e instalar a correção assim que ela sair. Fale conosco.

Pontos principais

  • A CVE-2026-98432 é uma falha do kernel do Linux com nota 9,8 de 10 dada pela equipe do kernel, que ataca o servidor remotamente durante o handshake TCP, antes de qualquer login.
  • O Debian já lançou a correção; Ubuntu e Red Hat ainda não tinham lançado até 30 de outubro de 2026.
  • Até lá: desative o MPTCP se não precisar dele, bloqueie pacotes TCP com opções de IPv4 e feche as portas que você não usa.
  • Instale o kernel corrigido assim que ele sair e reinicie; os passos temporários não o substituem.

Fontes