[ Início ]

Uma falha no código que o kernel Linux usa para abrir novas conexões TCP sobre IPv4 permite que um atacante remoto, sem senha e sem interação de ninguém, provoque corrupção de memória no kernel. O problema existe desde o Linux 4.4 (2016) e atinge, em princípio, qualquer servidor Linux que aceite conexões TCP por IPv4. A nota CVSS atribuída pela equipe de CVE do kernel é 9.8 (Crítica). Correções disponíveis na maioria das distribuições

O que torna o caso relevante é a demonstração, em laboratório, de execução remota de comandos como root contra servidores com um listener Multipath TCP (MPTCP). Essa demonstração foi publicada pela Anthropic em 27/10/2026, sem divulgação do código. Até a data deste alerta, não há registro de exploração em ataques reais e a CVE não consta do catálogo KEV da CISA.

O procedimento principal é  atualizar o kernel e reiniciar o servidor. As medidas paliativas descritas abaixo reduzem a exposição enquanto a atualização não chega, mas não a substituem.

O ataque depende de vencer uma condição de corrida, o que exige muitas tentativas. Então, não é motivo para pânico e não há código de exploração para execução remota publicado, até o momento de escrita desse alerta. A maioria das distribuições já tem correção. E há mitigações temporárias eficazes para reduzir a superfície de ataque.

Mas também não é motivo para esperar: a falha é alcançável pela rede, antes de qualquer autenticação, em qualquer porta TCP aberta. Tentativas mal-sucedidas podem derrubar o servidor (kernel panic). Provas de conceito que disparam a falha já circulam publicamente.

Ficha técnica

Como a falha funciona, em poucas palavras

Quando um pacote SYN chega com opções IP (por exemplo, Record Route ou Timestamp), o kernel guarda essas opções para usá-las na resposta SYN-ACK. Ao concluir o handshake, ele repassa essas opções ao novo socket sem copiá-las. Se, nesse mesmo instante, outro núcleo do processador estiver tratando um SYN retransmitido e o socket for encerrado, o kernel lê memória já liberada.

Com controle sobre o que ocupa essa memória, o atacante pode vazar conteúdo do kernel na resposta SYN-ACK (o que permite contornar o KASLR), escrever fora dos limites esperados ou travar o sistema. A correção faz o kernel aguardar um período de graça RCU antes de liberar essa memória.

Situação das correções por distribuição

O Apêncie 1, ao final  refletem as publicações oficiais até 03/11/2026 noon. Em kernels de distribuição, compare a versão do pacote com o aviso do fornecedor, e não com os números de versão do upstream.

Ações recomendadas, por ordem de prioridade

Prioridade 1 — Servidores expostos à Internet com listener MPTCP

É exatamente o cenário demonstrado em laboratório. Atenção especial a programas compilados com Go 1.24 ou superior, que abrem listeners com MPTCP por padrão no Linux. Exemplos incluem servidores web e proxies reversos escritos em Go, como Caddy e Traefik.

Descubra se o MPTCP está habilitado e quais serviços o utilizam:

sysctl net.mptcp.enabled
sudo ss -lnMp

Para verificar com qual versão do Go um binário foi compilado:

go version /caminho/para/o/binario

Prioridade 2 — Todos os servidores Linux com portas TCP abertas para a Internet

A falha está no TCP/IPv4 comum. Desabilitar o MPTCP não resolve o problema.

Prioridade 3 — Servidores internos, ambientes de desenvolvimento e estações de trabalho

Atualize no ciclo normal de manutenção, mas sem adiar.

Passo 1 — Verifique o kernel em execução

uname -r
# Debian/Ubuntu
dpkg -l 'linux-image*' | grep ^ii
# RHEL e derivados
rpm -q kernel

Para confirmar que a correção está presente no pacote instalado:

# Debian/Ubuntu
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -m1 CVE-2026-98432
# RHEL e derivados
rpm -q --changelog kernel-$(uname -r) | grep -m1 CVE-2026-98432

Passo 2 — Atualize e reinicie (correção definitiva)

# Debian
sudo apt update && sudo apt full-upgrade
# RHEL, AlmaLinux, Rocky, Oracle
sudo dnf upgrade kernel*

O kernel novo só passa a valer após o reinício. Para saber se a máquina está aguardando reboot:

# Debian/Ubuntu
ls /var/run/reboot-required 2>/dev/null && echo "Reinício pendente"
# RHEL e derivados
sudo needs-restarting -r

Containers: todos os containers compartilham o kernel do host. Quem precisa ser atualizado é o host (nó do Kubernetes, servidor Docker, hipervisor), e não as imagens dos containers.

Ubuntu 22.04, 24.04 e 26.04: um apt upgrade comum ainda não instala a correção, porque ela está no repositório de testes -proposed. Equipes que testam kernels antes de colocá-los em produção podem antecipá-la com os comandos publicados pela Canonical:

sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot

Para os demais casos, aplique as mitigações do Passo 3 e planeje a janela de reinício para quando o pacote chegar ao canal regular de atualizações.

Passo 3 — Mitigações temporárias (enquanto a atualização não é aplicada)

3a. Descartar pacotes TCP/IPv4 com opções IP

Esta é a regra nftables publicada pela Red Hat (RHSB-2026-016). Ela descarta pacotes TCP/IPv4 cujo cabeçalho IP tem mais de 20 bytes, ou seja, que carregam opções. Tráfego web, e-mail e SSH comum não usa opções IP.

Salve o conteúdo abaixo como cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Em seguida, valide, carregue e confirme:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Limitações que você precisa conhecer:

• A própria Red Hat afirma que a regra bloqueia o gatilho conhecido, mas não impede totalmente a exploração.
• A regra vale apenas para o tráfego destinado ao próprio host (hook input). Containers com namespace de rede próprio e VMs podem precisar de regra adicional, por exemplo no hook forward.
• Ela não persiste após reinício, a menos que seja incluída em /etc/nftables.conf.
• Ela quebra aplicações que dependem de opções IPv4, como rótulos de segurança CIPSO.
• Depois de aplicar o kernel corrigido, remova a regra: sudo nft delete table inet cve_2026_98432.

Para hosts que ainda usam iptables legado, há um equivalente com o módulo u32, aplicado na tabela raw, que também cobre tráfego encaminhado. Teste antes em homologação:

sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0x0F=6:15" -j DROP

3b. Desabilitar o MPTCP onde ele não for necessário

Esta medida remove a pré-condição do exploit demonstrado, mas não elimina a falha. A Canonical considera a atualização do kernel a única mitigação adequada.

sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf

A configuração vale por network namespace, então aplique-a também nos containers. Reinicie os serviços para que os listeners existentes sejam recriados sem MPTCP.

Em programas Go, também é possível desligar o MPTCP sem mexer no kernel:

# Em tempo de execução
GODEBUG=multipathtcp=0 ./servidor
# Em tempo de compilação (no go.mod do módulo principal)
godebug multipathtcp=0

3c. Reduzir a superfície exposta

Feche as portas que não são necessárias. Restrinja SSH e painéis administrativos a IPs conhecidos ou ao acesso via VPN.

Orientações por público

Empresas e equipes de TI

• Inventarie os servidores Linux expostos à Internet e classifique-os pelas prioridades acima. Não se esqueça de nós de Kubernetes, balanceadores, proxies reversos, gateways de VPN e appliances baseados em Linux.
• Peça formalmente aos fornecedores de appliances (firewalls, NAS, balanceadores, sistemas de câmeras, equipamentos industriais) uma posição sobre a CVE-2026-98432 e um prazo para correção.
• Em nuvem, consulte os boletins do seu provedor e atualize as imagens dos nós gerenciados.
• Registre evidências da correção (versão do kernel em execução após o reboot) para fins de auditoria e conformidade.

Provedores de Internet

• Corrija primeiro a própria infraestrutura Linux: resolvedores DNS, servidores RADIUS e de autenticação, concentradores PPPoE baseados em Linux, sistemas de gestão e cobrança, servidores web e de e-mail.
• Consulte os fabricantes de CPEs e equipamentos de rede baseados em Linux sobre o impacto em seus firmwares. Não presuma que estão afetados nem que estão imunes.
• Avalie, após uma janela de observação, filtrar na borda pacotes TCP com opções IP destinados a blocos de clientes de hospedagem e data center. Não descarte opções IP de forma indiscriminada: protocolos como IGMP e RSVP usam a opção Router Alert, e um filtro amplo pode afetar redes multicast.
• Comunique os clientes corporativos e de hospedagem de forma objetiva, com link para as correções do fornecedor de cada sistema operacional.
• Notifique o CERT.br sobre varreduras ou incidentes suspeitos relacionados.

Usuários domésticos

• Computadores pessoais com Linux normalmente não expõem serviços à Internet, o que torna o risco baixo. Mantenha as atualizações automáticas ativas e reinicie o computador quando o sistema pedir.
• Roteadores, NAS e outros dispositivos domésticos baseados em Linux: atualize o firmware quando o fabricante disponibilizar, desative a administração remota e revise os redirecionamentos de porta que não usa mais.

Detecção e caça a ameaças

Não há indicadores de comprometimento (IOCs) publicados até a data deste alerta: nenhum hash, endereço de C2 ou IP de atacante foi associado a campanhas. Há relatos, ainda não confirmados de forma independente, de varreduras direcionadas a serviços MPTCP na porta 443. Os sinais abaixo ajudam a priorizar investigações, mas não comprovam exploração.

Se houver suspeita de comprometimento, lembre que atualizar o kernel não remove um eventual acesso já obtido. Nesse caso, trate o servidor como comprometido: preserve evidências, investigue persistência, troque credenciais e considere reinstalar a máquina.

Apêndice 1 – Situação das correções

Referências

• CVE.org — CVE-2026-98432
• Kernel.org — commit de correção e3f33b0a1d89
• Canonical — Fixes available in -proposed pocket for CVE-2026-98432
• Ubuntu — página da CVE-2026-98432

Este alerta será atualizado conforme as distribuições publicarem novas correções, em especial a liberação dos kernels do Ubuntu LTS no canal regular de atualizações.