CVE-2026-98432: Falha Crítica no TCP do Kernel do Linux Permite Execução Remota de Código

Uma vulnerabilidade crítica na pilha de rede TCP IPv4 do kernel Linux pode permitir que um atacante remoto e não autenticado acione corrupção de memória, cause a quebra de sistemas vulneráveis e, potencialmente, execute código arbitrário com privilégios de root. Rastreadas como CVE-2026-98432, a falha possui uma pontuação CVSS 3.1 de 9.8 e existe no kernel Linux desde a versão 4.4.

A vulnerabilidade origina-se de uma condição de corrida que pode fazer com que o kernel acesse dados de opções IP após a memória subjacente já ter sido liberada. Um atacante capaz de alcançar um serviço TCP IPv4 exposto pode tentar acionar a condição usando solicitações de conexão especialmente cronometradas contendo opções IPv4. Nenhuma autenticação, privilégios locais ou interação do usuário são necessários.

O interesse em segurança aumentou significativamente depois que a Anthropic revelou que um modelo de pesquisa internamente desenvolvido havia criado um exploit funcional capaz de alcançar a execução remota de comandos como root contra um servidor Linux com um ouvinte Multipath TCP (MPTCP). O exploit primeiro vaza um ponteiro do kernel para contornar a KASLR e, em seguida, usa a mesma condição de uso após liberação para corromper a memória e redirecionar o fluxo de controle do kernel. A Anthropic não divulgou o código do exploit.

Importante, a vulnerabilidade subjacente não se limita ao MPTCP. A Red Hat confirma que sistemas com redes TCP IPv4 comuns continuam vulneráveis mesmo quando o MPTCP está desativado, incluindo as configurações padrão do Red Hat Enterprise Linux.

Contate Vendas

Em 4 de novembro de 2026, nenhum fornecedor de Linux, CERT ou outra fonte revisada relatou exploração confirmada da falha em ataques do mundo real. Existe código de pesquisa pública demonstrando partes da vulnerabilidade, mas ainda não foi documentado um exploit públicamente lançado fornecendo a plena capacidade de root remoto demonstrada pela Anthropic.

Equipes de segurança podem usar a Plataforma de Inteligência de Detecção de IA Nativa da SOC Prime para fortalecer suas defesas contra a exploração de vulnerabilidades emergentes, operacionalizar inteligência de ameaças e acelerar a caça às ameaças em ambientes SIEM, EDR, XDR e Data Lake.

Detecte CVE-2026-98432 monitorando tráfego TCP IPv4 incomum contendo opções IP, tentativas de conexão repetidas projetadas para acionar condições de corrida, falhas no kernel ou eventos de corrupção de memória e atividade suspeita que possa indicar pós-exploração bem-sucedida.

Conteúdo de detecção pode não estar disponível para cada CVE. Verifique a Plataforma SOC Prime para cobertura atual. Se detecções relevantes ainda não estiverem disponíveis, verifique novamente conforme novas inteligências de ameaças e conteúdo de detecção são continuamente adicionados.

Análise do CVE-2026-98432

CVE-2026-98432 afeta o código de gerenciamento de conexão TCP IPv4 em kernels Linux que contêm a implementação vulnerável introduzida no Linux 4.4. A equipe de CVE do kernel Linux classifica o problema como crítico com uma pontuação CVSS 3.1 de 9.8 e o vetor AV/AC/PR/UI/S/C/I/A.

A vulnerabilidade é uma condição de uso após liberação causada por uma corrida durante o processamento simultâneo de conexões TCP. Quando uma conexão TCP IPv4 é estabelecida, tcp_v4_syn_recv_sock() transfere opções IP associadas à solicitação pendente para o soquete recém-criado sem fazer uma cópia separada.

Outra CPU pode processar simultaneamente um SYN retransmitido associado ao mesmo soquete de solicitação. Durante esse processo, funções responsáveis por gerar o SYN-ACK continuam lendo as opções IP enquanto protegidas por uma seção crítica de leitura do RCU.

No entanto, o soquete filho pode ser destruído enquanto essa operação ainda está em andamento. O kernel, então, libera a estrutura inet_opt associada usando kfree(), deixando outra CPU potencialmente acessando memória que já foi liberada. A referência obsoleta resultante cria uma condição de uso após liberação em ip_options_build().

Uma corrida semelhante existe durante a migração do soquete de solicitação, incluindo configurações usando net.ipv4.tcp_migrate_req=1 ou SK_REUSEPORT_SELECT_OR_MIGRATE baseado em BPF. A correção upstream substitui a liberação de memória insegura por uma liberação ciente de RCU, garantindo que os leitores tenham terminado de acessar o objeto antes que sua memória possa ser recuperada.

O primeiro problema afeta especificamente o IPv4. O aviso do kernel afirma que o IPv6 não é vulnerável a essa corrida em particular porque tcp_v6_syn_recv_sock() duplica as opções relevantes em vez de transferi-las da mesma maneira.

A exploração remota requer tráfego de rede especialmente construído e manipulação precisa da condição de corrida. A Red Hat observa que os resultados prováveis podem incluir uma falha no kernel, corrupção de memória e, potencialmente, execução remota de código. A falta de autenticação e interação do usuário aumenta substancialmente o risco para sistemas expondo serviços TCP a redes não confiáveis.

A Anthropic demonstrou que a vulnerabilidade pode ser transformada em um exploit de root remoto completo. Seu modelo de pesquisa direcionou um servidor Linux aceitando conexões de Multipath TCP e usou duas etapas para alcançar a execução de comandos.

Durante a primeira etapa, o exploit aciona repetidamente a corrida e manipula um valor de comprimento para que o kernel retorne memória adjacente adicional em uma resposta de rede. Eventualmente, uma dessas respostas contém um ponteiro do kernel. Essa divulgação revela informações sobre o layout da memória do kernel e permite que o exploit supere a Randomização do Layout do Espaço de Endereçamento do Kernel (KASLR).

Durante a segunda etapa, o exploit usa a mesma vulnerabilidade para causar um estouro de buffer e sobrescrever um ponteiro de retorno. O ponteiro é redirecionado para uma carga útil anteriormente colocada na memória do kernel usando a funcionalidade legítima do protocolo. Quando o kernel invoca o retorno modificado, as funções existentes do kernel são encadeadas até que um comando de shell selecionado pelo atacante seja executado como root.

Uma característica particularmente importante do exploit é que perder a corrida não necessariamente quebra o servidor. Em vez disso, a tentativa de conexão pode simplesmente falhar, permitindo que o atacante tente repetidamente. No ambiente de teste da Anthropic, obter um ponteiro de kernel útil levou aproximadamente 48 minutos, seguidos de mais cinco minutos para alcançar a execução de comandos como root.

Essa demonstração não deve ser interpretada como se o MPTCP fosse necessário para exploração. A Anthropic demonstrou um caminho de exploit bem-sucedido envolvendo um ouvinte MPTCP, mas o código vulnerável reside no tratamento TCP IPv4 comum. A Red Hat explicitamente alerta que desabilitar o MPTCP não aborda completamente a vulnerabilidade e que as instalações padrão do RHEL permanecem afetadas, mesmo que o MPTCP esteja desativado por padrão.

A situação do PoC CVE-2026-98432 também é importante distinguir da existência de um exploit completo e armado. A Anthropic desenvolveu internamente um proof of concept funcional de root remoto, mas não o publicou. Código público relatado por pesquisadores de segurança pode demonstrar ou detectar aspectos da corrida subjacente e divulgação de memória, mas as fontes revisadas não documentam código publicamente lançado reproduzindo o encadeamento completo de execução de código remoto da Anthropic.

A vulnerabilidade foi relatada pelo pesquisador da Anthropic Xinyang Ge. A correção upstream para Linux foi aplicada em 5 de outubro de 2026, enquanto o registro CVE do kernel Linux foi publicado em 15 de outubro. A Anthropic descreveu publicamente sua pesquisa completa de exploração em 27 de outubro.

O projeto do kernel Linux identifica as seguintes versões fixas upstream:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

A equipe do kernel recomenda a atualização para o kernel estável mais recente em vez de selecionar individualmente commits.

A exposição e a remediação específicas da distribuição diferem porque os fornecedores de Linux mantêm seus próprios kernels e realizam correções de segurança. A Red Hat atualmente classifica a questão como Crítica em 9.8 e lançou correções para múltiplos streams RHEL 8, 9 e 10. Produtos OpenShift e camadas que dependem de kernels RHEL afetados também requerem atenção.

O Ubuntu também classifica a vulnerabilidade como Crítica em 9.8. O Ubuntu 26.10 recebeu um kernel genérico corrigido, enquanto correções para o Ubuntu 22.04 LTS, 24.04 LTS e 26.04 LTS estavam disponíveis no pocket de teste -proposed no início de novembro, com lançamentos adicionais suportados aguardando correções. Administradores devem usar a página CVE da Canonical em vez de confiar exclusivamente nos números de versão do kernel upstream.

Para detecção de CVE-2026-98432, equipes de segurança devem combinar telemetria de rede e host. Sinais de caça em nível de rede potenciais incluem pacotes TCP IPv4 de entrada incomuns transportando opções IP, especialmente tentativas de conexão repetidas contendo opções de Rota de Registro ou Timestamp e padrões anormais de retransmissão de SYN. A presença de tal tráfego isoladamente não confirma exploração, mas fornece um pivô de caça útil quando correlacionado com sistemas vulneráveis.

A monitoração em nível de host deve incluir falhas no kernel Linux, avisos do kernel, indicadores de corrupção de memória, reinícios inesperados de serviço e atividade anômala imediatamente após tráfego de rede suspeito. Como a exploração bem-sucedida poderia teoricamente fornecer execução de código root, os defensores também devem monitorar por processos privilegiados inesperados, novos arquivos criados, mudanças de configuração, mecanismos de persistência e conexões de saída não explicadas.

Atualmente, não existem IOC específicos para CVE-2026-98432, como endereços IP maliciosos confirmados, domínios ou hashes de malware porque as fontes revisadas não relataram exploração do mundo real. Portanto, os defensores devem priorizar a detecção baseada em comportamento e avaliação de exposição em vez de confiar em indicadores estáticos.

Mitigação CVE-2026-98432

A remediação definitiva é instalar um kernel fornecido pelo fornecedor contendo a correção de segurança. A equipe do CVE do kernel Linux recomenda mover para o kernel estável mais recente suportado, enquanto usuários de distribuições Linux devem instalar pacotes fornecidos especificamente por seu fornecedor, porque as correções são comumente retroportadas sem alteração para uma versão de kernel upstream.

Administradores devem priorizar servidores Linux voltados para a internet e outros sistemas aceitando conexões TCP IPv4 de entrada. A superfície de ataque é ampla porque a vulnerabilidade existe na pilha de rede do kernel e não em um aplicativo ou produto de servidor individual.

As organizações devem tomar os seguintes passos:

1. Inventariar servidores Linux e identificar o kernel em execução com ferramentas como uname -r.
2. Verifique o aviso de segurança da distribuição Linux relevante em vez de determinar a exposição somente pelo número da versão upstream.
3. Instale o kernel corrigido fornecido pelo fornecedor assim que estiver disponível.
4. Reinicie os sistemas afetados após instalar o kernel atualizado para garantir que o kernel corrigido esteja em execução.
5. Priorize servidores voltados para a internet e infraestrutura aceitando tráfego TCP IPv4 de entrada.
6. Reveja serviços TCP expostos externamente e limite a acessibilidade de rede desnecessária.
7. Continue monitorando avisos de fornecedores porque a disponibilidade de correções difere entre distribuições Linux, variantes de kernel, kernels em nuvem e canais de suporte.

A Red Hat e o Ubuntu também documentaram uma abordagem de filtragem de pacotes interina que descarta pacotes TCP IPv4 de entrada contendo opções IP. A condição recomendada de nftables verifica um comprimento de cabeçalho IPv4 maior que cinco e descarta os pacotes TCP correspondentes antes que eles alcancem o caminho de manuseio de soquetes vulnerável.

Essa medida pode reduzir a exposição porque o caminho de exploração conhecido requer opções IPv4. No entanto, ambos os fornecedores alertam que a filtragem de pacotes não é um substituto completo para a instalação do kernel corrigido. Também pode interferir em cargas de trabalho que dependem legitimamente de opções IPv4 e, portanto, devem ser testadas antes da implantação em produção.

Desativar o MPTCP por si só não deve ser tratado como proteção suficiente. Embora o exploit funcional da Anthropic tenha como alvo um ouvinte MPTCP, a vulnerabilidade subjacente está no tratamento normal do TCP IPv4. A Red Hat especificamente observa que o RHEL permanece vulnerável em sua configuração padrão, mesmo que o MPTCP esteja desativado.

Para ambientes que usam aplicações Go, desabilitar o comportamento automático do MPTCP pode reduzir a exposição ao exploit específico demonstrado pela Anthropic, mas isso continua sendo uma medida incompleta de redução de risco. Sistemas sem um ouvinte MPTCP não devem ser considerados automaticamente seguros, pois outras técnicas de exploração podem direcionar a mesma corrida subjacente.

Como nenhuma campanha de comprometimento do mundo real foi confirmada, a orientação de resposta a incidentes deve atualmente se concentrar na identificação de sistemas potencialmente vulneráveis e comportamento de exploração suspeito em vez de procurar por um conjunto de infraestrutura conhecido de atacantes. Organizações que observam tráfego TCP incomum seguido de instabilidade no kernel ou execução privilegiada inesperada devem tratar a atividade como potencialmente maliciosa e preservar a telemetria de rede e host para investigação.