Falha crítica no Linux expõe 100% servidores a invasão root hoje
Vulnerabilidade CVE-2026-98432 afeta kernels Linux desde a versão 4.4 e permite execução remota de código como root via handshake TCP IPv4. Patches já existem, mas grandes distribuições ainda não liberaram correção para todos os usuários.
Segurança
Vulnerabilidade grave no kernel Linux permite invasão remota com privilégios de root em todos os servidores afetados.
Leia também: Anthropic abre lista para Claude Duet, IA sempre ativa nos EUA
Uma falha crítica no kernel Linux, identificada como CVE-2026-98432, permite que um invasor remoto, sem autenticação, execute comandos com privilégios de root durante o handshake TCP IPv4 em servidores com listener multipath TCP (MPTCP). O bug, presente em kernels a partir da versão 4.4, já foi corrigido nas versões estáveis lançadas em 11 e 15 de outubro, mas distribuições populares como Ubuntu e Red Hat Enterprise Linux (RHEL) 8, 9 e 10 ainda não disponibilizaram atualizações para todos os usuários até o fim de outubro, mantendo muitos sistemas expostos.
Falha no handshake TCP atinge qualquer servidor IPv4
A vulnerabilidade aparece no código que todo servidor Linux executa ao aceitar uma conexão TCP IPv4, antes mesmo que qualquer aplicação toque na conexão. O problema está em como o kernel trata as opções IPv4 presentes no pacote inicial SYN, como Record Route ou Timestamp, durante o handshake.
Quando o servidor recebe uma conexão, o kernel guarda essas opções em uma estrutura leve de “request socket” e depois as transfere para o socket final. O erro é que essa transferência é feita por referência, sem cópia: as opções são passadas diretamente e, em seguida, a memória é liberada assim que a conexão termina. Em sistemas com múltiplas CPUs, outra CPU pode ainda estar lendo esses dados já liberados, caracterizando um use-after-free.
Nessa condição de corrida, o invasor consegue provocar vazamento de memória do kernel, corrupção de dados e, em configurações específicas com listener MPTCP, chegar à execução remota de código como root. Como tudo acontece antes de qualquer autenticação, basta que o servidor aceite conexões TCP IPv4 em uma porta aberta.
Entenda o contexto
A vulnerabilidade foi reportada por um pesquisador da Anthropic, que também desenvolveu um exploit funcional. Segundo a empresa, o código de prova de conceito consegue abrir um shell remoto com privilégios de root em “servidores Linux com um listener multipath TCP”, sem qualquer credencial.
O CNA (autoridade de numeração de vulnerabilidades) do próprio kernel Linux classificou o problema com pontuação CVSS 3.1 de 9,8, grau crítico. Já a Red Hat atribui nota 8,1, alegando alta complexidade de ataque e descrevendo o impacto sobretudo como travamentos ou possível corrupção de memória. A Anthropic contesta, na prática, essa leitura mais branda ao demonstrar uma exploração com acesso root em laboratório.
Em comunicado técnico, a empresa afirma que, quando o invasor perde a corrida de memória, o resultado costuma ser apenas a falha do handshake, sem derrubar o servidor. “A lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed”, diz o pesquisador que assinou o relatório.
Quais versões do kernel já foram corrigidas?
As correções para o CVE-2026-98432 já fazem parte das séries estáveis do kernel Linux distribuídas em outubro. Estão protegidos os kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3, além de derivados que incorporam o mesmo patch. A falha existe em todas as versões desde a 4.4 que ainda não receberam a correção.
A mudança técnica foi proposta pelo desenvolvedor do kernel Eric Dumazet, no commit intitulado “ipv4: free inet_opt and ireq_opt after an RCU grace period”. No patch, duas chamadas à função kfree(), que libera imediatamente a memória, são substituídas por kfree_rcu(), que espera um “período de graça” do mecanismo RCU antes de efetivamente liberar os dados, garantindo que nenhuma CPU ainda esteja lendo aquela área de memória.
O mesmo commit ajusta caminhos de código relacionados à migração de request-socket, usada em configurações avançadas como net.ipv4.tcp_migrate_req=1 ou em programas BPF que atuam em seleção e migração de conexões. Em nota incluída no patch, Dumazet reforça que o impacto inicial é restrito ao IPv4: “IPv6 is not affected by the first issue.” Uma situação parecida em IPv6, segundo ele, será tratada em um patch separado.
Distribuições ainda correm atrás do prejuízo
Apesar de o código corrigido já estar disponível em upstream, a atualização não chegou a todos os usuários finais. Até 29 de outubro, os trackers de segurança indicavam que Ubuntu e RHEL 8, 9 e 10 permaneciam vulneráveis, sem patch liberado em seus kernels distribuídos oficialmente. Em outras plataformas, como Debian, SUSE Linux Enterprise Server 16 e a linha 15 LTSS, além dos kernels UEK do Oracle Linux e alguns kernels do Amazon Linux 2023, a correção já foi integrada.
Essa defasagem cria uma janela de risco significativa, sobretudo em provedores de nuvem, data centers, bancos, órgãos públicos e empresas de tecnologia que dependem de Linux em ambiente de produção. Como containers compartilham o kernel do host, não adianta apenas atualizar a imagem de aplicação: se o kernel do host estiver vulnerável, todos os containers que ele executa também estarão.
Como a vulnerabilidade é explorada na prática?
Na exploração descrita pela Anthropic, o ataque acontece exclusivamente durante o handshake TCP, antes que qualquer aplicação receba a conexão. O invasor envia pacotes SYN IPv4 com opções específicas no cabeçalho — como Record Route ou Timestamp — direcionados a um servidor que tenha pelo menos um listener MPTCP ativo.
A partir daí, o exploit força repetidamente a condição de corrida no kernel, tentando acessar a memória já liberada e manipular o conteúdo de forma a redirecionar a execução interna. Depois de vazar dados sensíveis do heap do kernel, o atacante usa essas informações para calibrar um ataque de corrupção de memória que, ao fim da cadeia, rende execução de comandos arbitrários como root.
Segundo a Anthropic, o protótipo de ataque leva cerca de 48 minutos para vazar um ponteiro válido do kernel e mais cinco minutos para chegar a comandos remotos com privilégios de superusuário, em uma das configurações testadas. O exploit não foi publicado, e a política de divulgação da empresa prevê 90 dias para que desenvolvedores lancem patches e outros 45 dias antes da divulgação de detalhes técnicos além do aviso público.
Impacto em servidores, nuvem e containers
O risco é maior em servidores Linux expostos à internet ou a redes não confiáveis que aceitem conexões TCP IPv4, em especial quando executam serviços que usam MPTCP. Em clusters Kubernetes e outros orquestradores de containers, o impacto se estende a todo o ambiente: um único nó com kernel vulnerável pode comprometer múltiplas aplicações teoricamente isoladas, já que todas compartilham o mesmo kernel.
Além da possibilidade de invasão com acesso root, o use-after-free também pode levar a vazamento de memória sensível do kernel para o atacante, corrupção de estruturas internas e travamentos, afetando diretamente a disponibilidade de serviços críticos.
O que administradores devem fazer agora?
A orientação principal para administradores de sistemas é atualizar o kernel para uma versão corrigida assim que a distribuição disponibilizar o patch e, em seguida, reiniciar o servidor para que o novo kernel entre em uso. Sem reboot, a vulnerabilidade continua ativa, mesmo após a instalação do pacote.
Em hosts de containers e nós Kubernetes, a atualização deve ser sempre aplicada no nível do host. Verificações feitas dentro de containers apenas refletem o kernel do host, não trazem proteção adicional. Ferramentas como o comando ss -M ajudam a identificar se há listeners MPTCP ativos; um resultado vazio indica que não há sockets MPTCP escutando, embora isso não elimine a necessidade do patch, já que o bug está no caminho genérico de handshake IPv4.
Enquanto o patch não chega, especialistas sugerem medidas provisórias, como manter listeners MPTCP fora da internet pública e priorizar esses servidores na fila de atualização. Também é possível, em alguns ambientes, filtrar em firewalls pacotes IPv4 com opções no cabeçalho, já que é raro que aplicações legítimas usem essas opções em tráfego TCP comum. Essa mitigação, no entanto, não substitui a correção no kernel.
No lado do desenvolvimento do kernel, a correção de CVE-2026-98432 reacende o debate sobre como vulnerabilidades de corrida de memória em componentes centrais da pilha de rede podem ser exploradas em larga escala, especialmente com o apoio de ferramentas automatizadas de geração de código de ataque. A expectativa na comunidade é que distribuições ainda pendentes acelerem a liberação de kernels corrigidos nos próximos dias, reduzindo a janela de exposição em infraestruturas críticas.
