CVE-2026-98432, falha TCP no Linux: como proteger servidores

O que é a CVE-2026-98432?

A CVE-2026-98432 é uma vulnerabilidade no kernel Linux, o núcleo dos sistemas operacionais Linux. Seu título oficial é ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. A equipe de CVE do kernel Linux atribuiu o identificador e publicou o registro em 15 de outubro de 2026 ^[1]. O registro atribui a ela uma pontuação base CVSS 3.1 de 9,8, classificada como Crítica ^[1].

A falha é um use-after-free: um programa continua usando um trecho de memória depois de liberá-lo, de modo que essa memória pode já conter outros dados. Neste caso, ela está no código que trata solicitações de conexão TCP IPv4 recebidas ^[10]. O vetor CVSS é AV:N/AC:L/PR:N/UI:N. Isso significa que o ataque funciona pela rede, tem baixa complexidade e não exige privilégios nem interação do usuário ^[1].

O bug existe desde o Linux 4.4, onde chegou com o commit 079096f103fa ^[2]. Uma correção escrita por Eric Dumazet foi incorporada em 5 de outubro de 2026 e já está no kernel mainline ^[3]. Ela foi portada para os ramos estáveis mantidos ^[2][4].

Quais sistemas são afetados?

A Red Hat diz que a falha afeta qualquer sistema que execute um kernel vulnerável com rede TCP IPv4 habilitada. Os sistemas que aceitam conexões TCP de entrada são os mais diretamente expostos ^[6]. A AlmaLinux recomenda tratar como exposto qualquer sistema que aceite conexões TCP IPv4 vindas de redes não confiáveis ^[10]. O IPv6 não é afetado pelo problema principal ^[2].

Como a vulnerabilidade funciona?

Uma conexão TCP começa com um handshake. O cliente envia um pacote SYN, o servidor responde com um SYN-ACK e o cliente confirma. Um SYN pode levar opções IPv4, que são campos extras opcionais no cabeçalho IP. Record Route e Timestamp são dois exemplos ^[1].

Segundo a descrição do kernel, a função tcp_v4_syn_recv_sock() entrega as opções salvas ao novo socket filho sem copiá-las ^[2]. Enquanto isso, outro núcleo da CPU pode processar um SYN retransmitido para a mesma solicitação e montar um SYN-ACK que lê essas opções ^[2]. Nada impede que o socket filho seja liberado enquanto o SYN-ACK ainda está sendo montado. Suas opções são liberadas com um kfree() simples, e assim o kernel lê memória já liberada em ip_options_build() ^[2].

Uma segunda condição de corrida semelhante ocorre quando a migração de request sockets está ativada, seja por net.ipv4.tcp_migrate_req=1, seja por um programa BPF de reuseport ^[2]. A correção faz os dois caminhos de liberação aguardarem um período de carência do RCU, usando kfree_rcu() em inet_sock_destruct() e tcp_v4_reqsk_destructor() ^[2]. O RCU (read-copy-update) é uma técnica do kernel que adia a liberação de memória até que nenhum leitor possa mais estar usando-a.

O que um atacante poderia fazer com ela?

As notas de pontuação do registro da CVE descrevem três impactos ^[1]:

• Divulgação de informações: a memória liberada pode ser reutilizada por outros dados, e seu conteúdo pode ser copiado para o SYN-ACK enviado de volta ao atacante ^[1].
• Corrupção de memória: comprimentos e deslocamentos obsoletos podem direcionar escritas do kernel para fora dos limites, com possível corrupção do fluxo de controle ^[1].
• Travamentos: um valor de comprimento reutilizado pode provocar um kernel panic, e as escritas indevidas também podem derrubar o kernel ^[1].

A Red Hat acrescenta que executar código de forma confiável por meio desse bug, sensível a tempo, exige controle preciso do heap. Mesmo assim, ela classifica o bug como Crítico, porque não há pré-requisitos de rede e ele pode causar instabilidade grave ^[7].

O que a Anthropic divulgou e qual é o papel do MPTCP?

Em 27 de outubro de 2026, o Frontier Red Team da Anthropic publicou um relato das vulnerabilidades que encontrou usando modelos Claude ^[4][11]. Sobre a CVE-2026-98432, a empresa diz que a equipe criou um exploit que permite a um atacante remoto executar comandos arbitrários como root em servidores Linux com um listener Multipath TCP (MPTCP), sem credenciais nem interação do usuário ^[4]. O MPTCP é uma extensão do TCP que permite a uma única conexão usar vários caminhos de rede ao mesmo tempo.

A Anthropic descreve duas etapas. Primeiro, o exploit vaza um ponteiro do kernel para contornar o KASLR, a randomização de endereços do kernel. Depois, sobrescreve um ponteiro de callback para que o kernel execute como root um comando escolhido pelo atacante ^[4]. Uma corrida perdida apenas faz o handshake falhar e não derruba o sistema, então o atacante pode continuar tentando ^[4]. Na prova de conceito da Anthropic, vazar um ponteiro do kernel levou 48 minutos, e a execução de comandos levou mais cinco minutos ^[4].

O MPTCP é necessário?

Não, segundo os fornecedores que o avaliaram. A Red Hat afirma que o MPTCP não é condição necessária para essa falha e que sistemas com MPTCP desativado continuam afetados ^[6]. A equipe de segurança do Go diz que o exploit demonstrado precisa de um listener MPTCP, mas que o bug subjacente não é específico do MPTCP ^[5]. O Go é relevante aqui porque, desde o Go 1.24, os programas em Go ativam o MPTCP por padrão em sockets de escuta no Linux ^[5].

Segundo a Akamai, a Anthropic não divulgou seu exploit de root, e em 2 de novembro de 2026 a Akamai disse não ter conhecimento de um exploit público funcional ^[11].

Quais versões do kernel e distribuições estão corrigidas?

A equipe de CVE do kernel lista estas correções upstream: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e o mainline 7.3 ^[2]. A maioria das pessoas, porém, usa um kernel compilado pela sua distribuição, que adota numeração própria. Consulte o boletim da sua distribuição em vez de comparar números upstream.

Situação em 3 de novembro de 2026:

• Red Hat Enterprise Linux: kernels corrigidos foram lançados em 1 de novembro de 2026 para RHEL 8, 9 e 10. RHEL 6 e 7 aparecem como não afetados. O kernel de tempo real do RHEL 9 e as imagens de nó do OpenShift ainda aparecem como afetados ^[7].
• Ubuntu: o Ubuntu classifica o problema como Crítico. Seu rastreador mostra 26.10, 26.04 LTS, 24.04 LTS e 22.04 LTS como vulneráveis, com correções em andamento; 20.04, 18.04 e 16.04 também aparecem como vulneráveis, e 14.04 como não afetado ^[8].
• Debian: há correções para o Debian 12 bookworm (linux 6.1.190-1 e linux-6.12 6.12.113-1~deb12u1) e o Debian 13 trixie (linux 6.12.113-1), além do unstable ^[9].
• AlmaLinux: kernels corrigidos para AlmaLinux 8, 9 e 10 estão nos repositórios de produção ^[10].
• Outros: a Akamai informou que SUSE, Oracle Linux e Amazon Linux 2023 haviam lançado kernels corrigidos para algumas versões até 30 de outubro de 2026 ^[11].

E os celulares Android?

O Android usa o kernel Linux, mas o Android Security Bulletin publicado em 2 de novembro de 2026 não lista a CVE-2026-98432 ^[13]. Donos de celulares devem instalar as atualizações de segurança à medida que o fabricante as liberar.

Como verificar se um servidor está vulnerável?

1. Descubra o kernel em execução. Execute uname -r. Uma correção só vale depois que a máquina reinicia com o novo kernel. A AlmaLinux orienta os usuários a reiniciar e confirmar a versão com uname -r ^[10].
2. Compare com o rastreador do seu fornecedor. Procure a CVE-2026-98432 na página de segurança da sua distribuição. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] e AlmaLinux ^[10] listam as versões de pacote que contêm a correção.
3. Verifique o MPTCP. sysctl net.mptcp.enabled mostra se o MPTCP está ativado. sudo ss -lnMp lista os listeners MPTCP e os processos donos deles ^[10]. A Akamai também sugere verificar net.ipv4.tcp_migrate_req ^[11].
4. Procure serviços em Go. Programas compilados com Go 1.24 ou posterior abrem listeners MPTCP por padrão no Linux ^[5]. Qualquer serviço em Go que você execute pode, portanto, expor o caminho explorado pela Anthropic.
5. Verifique produtos derivados. A Red Hat alerta que qualquer produto construído sobre o kernel do RHEL, incluindo OpenShift, OpenStack e Red Hat Virtualization, também pode ser afetado ^[6].

Como corrigir ou mitigar a CVE-2026-98432?

A correção de verdade é um kernel com patch. A Red Hat considera a aplicação das atualizações do kernel a única solução completa ^[6], e a equipe de segurança do Go diz que a melhor correção é atualizar para um kernel corrigido ^[5]. Instale a atualização de kernel da sua distribuição, reinicie e confirme a versão em execução.

O que fazer antes de o patch chegar?

• Descarte pacotes TCP com opções IPv4. A Red Hat publica, e o rastreador do Ubuntu lista como solução de contorno enviada por usuários, uma regra nftables que descarta pacotes TCP IPv4 de entrada cujo cabeçalho IP seja maior que os 20 bytes básicos, ou seja, pacotes com opções (ip hdrlength > 5) ^[6][8]. Opções TCP normais, como timestamps e window scaling, ficam no cabeçalho TCP e não são afetadas ^[8]. Os dois fornecedores dizem que a regra reduz o risco, mas não impede totalmente a exploração ^[6][8].
• Conheça os limites da regra. A AlmaLinux observa que a versão dela não sobrevive a uma reinicialização, que o tráfego entre contêineres no mesmo host pode contorná-la, que ela também descarta pacotes encaminhados em hosts de roteamento e que quebra redes que dependem de rótulos CIPSO/NetLabel ^[10]. O Ubuntu observa que contêineres com rede separada precisam da regra aplicada separadamente ^[8].
• Desative o MPTCP se não precisar dele. Definir net.mptcp.enabled=0 desliga o MPTCP em todo o sistema ^[10]. A Akamai também sugere definir net.ipv4.tcp_migrate_req=0 ^[11]. A Akamai alerta que desativar apenas o MPTCP não impede a exploração; só reduz a chance de disparar a condição de corrida ^[11]. Programas em Go também podem desativá-lo com GODEBUG=multipathtcp=0, mas a equipe do Go considera frágeis as desativações por programa ^[5].
• Filtre na borda. Para o OpenShift, a Red Hat observa que regras em um nó não filtram o tráfego entre pods, enquanto a filtragem no limite da rede, à frente do cluster, evita essa limitação ^[6].

O init_on_free=1 ajuda?

Uma publicação na lista oss-security sugeriu a opção de boot init_on_free=1 como paliativo extra. Um membro da equipe de kernel da CIQ respondeu que ela não mitiga essa CVE de forma significativa e não deveria ter peso em boletins ^[12]. Trate-a como hardening geral, não como mitigação para este bug.

A CVE-2026-98432 está sendo explorada?

Em 3 de novembro de 2026, a CVE-2026-98432 não aparecia no catálogo Known Exploited Vulnerabilities da CISA, a lista do governo dos EUA de falhas com exploração real confirmada ^[14]. A Akamai disse em 2 de novembro de 2026 que não tinha conhecimento de um exploit público funcional ^[11]. Isso não prova que ninguém esteja explorando o bug. Já se demonstrou que existe um exploit confiável ^[4], e os detalhes técnicos estão públicos na correção do kernel ^[3].

A percepção de gravidade também mudou com o tempo. A CVE foi publicada inicialmente em 15 de outubro de 2026 ^[1]. A atenção maior veio depois do relato da Anthropic de 27 de outubro ^[4][11]. Boletins de fornecedores com mitigações provisórias saíram entre 29 de outubro e 2 de novembro ^[5][6][10]. Administradores que só passaram os olhos pelo registro original podem ter perdido as orientações posteriores.

O que vem a seguir?

A Red Hat descreve sua investigação como em andamento e diz que o boletim será atualizado à medida que surgirem novas informações ^[6]. Espere que os pacotes restantes, como o kernel de tempo real do RHEL 9 e as imagens do OpenShift ^[7] e os kernels do Ubuntu ainda em andamento ^[8], recebam correções nos próximos dias ou semanas. Consulte os rastreadores dos fornecedores em vez de resumos de notícias, porque essas páginas mudaram várias vezes nas primeiras semanas.

A correção do kernel também deixa uma questão relacionada em aberto. A descrição do kernel diz que a função tcp_v6_reqsk_destructor() do IPv6 tem o mesmo problema de migração com opções definidas apenas pelo CALIPSO, e que isso será tratado em um patch separado ^[2]. Pela política de divulgação coordenada da Anthropic, a empresa concede 90 dias para a aplicação de patches e mais 45 dias antes de discutir detalhes além do boletim público ^[4]. Portanto, mais detalhes técnicos podem surgir depois.

Estas são informações técnicas gerais e não substituem o boletim de segurança do seu fornecedor nem o processo de resposta a incidentes da sua organização.