TL;DR
A CVE-2026-98432 é uma falha na forma como o kernel do Linux estabelece ligações TCP IPv4, presente no kernel 4.4 e versões posteriores. A própria equipa CVE do kernel atribui-lhe uma classificação de 9,8 em 10. A Anthropic relata que um modelo de investigação Claude, ainda não divulgado, criou um exploit que concede a um atacante remoto privilégios de root num servidor Linux com um listener MPTCP (Multipath TCP), sem necessidade de credenciais nem interação do utilizador. A AWS confirma que, em condições específicas, um atacante remoto não autenticado poderia obter execução remota de código. Até 2 de novembro, nenhum fornecedor ou CERT tinha relatado ataques em circulação e o CVE não constava do catálogo de «Vulnerabilidades Exploradas Conhecidas» da CISA. O investigador Marcus Hutchins relatou, entretanto, o que parecem ser agentes maliciosos a varrer a Internet em busca de servidores com MPTCP ativado.
Como corrigir a vulnerabilidade CVE-2026-98432
Instale um kernel corrigido e reinicie o sistema. A AWS considera esta a única solução completa e afirma que um «livepatch» também resolve o problema.
Identifique primeiro todas as máquinas virtuais afetadas. Inclua os hosts que se tenham esquecido e os nós sob os seus contentores. A funcionalidade «Máquinas Virtuais» emAikidoassinala as que estão a executar um kernel afetado.
Amazon Linux. Estão disponíveis pacotes de kernel corrigidos para o Amazon Linux 2 e 2023, abrangendo os kernels 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 e 6.18.
- Amazon Linux 2: sudo yum update kernel && sudo reboot
- Amazon Linux 2023: sudo dnf update kernel --releasever=latest && sudo reboot
Kubernetes, ECS e outros serviços geridos da AWS
- EKS: atualize os grupos de nós geridos, os nós autogeridos e os nós Karpenter para a versão AMI v20261031 ou posterior. O Modo Automático do EKS substitui os nós automaticamente.
- ECS no EC2: atualize o kernel e reinicie, ou substitua as instâncias pela AMI otimizada para ECS, versão 20261031.
- Fargate: as novas tarefas lançadas após 1 de novembro de 2026, às 06:00 PDT, utilizam a plataforma atualizada. As tarefas existentes serão desativadas de acordo com as suas definições de desativação de tarefas, ou poderá substituí-las mais cedo.
- Bottlerocket: esperava-se que as AMIs atualizadas estivessem disponíveis a partir de 2 de novembro.
Outras distribuições. Verifique o sistema de acompanhamento do seu fornecedor, pois o estado muda diariamente.
- Ubuntu: a versão 26.10 está corrigida na 7.3.0-10.10. As correções para a 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) e 26.04 (7.0.0-43.43) encontram-se no repositório de testes -proposed, do qual o apt não instala por predefinição; por isso, é necessário ativá-lo e instalar o kernel explicitamente utilizando os comandos indicados na publicação da Canonical. As versões 16.04, 18.04 e 20.04 ainda apresentam uma correção pendente, e os kernels para a nuvem, FIPS e em tempo real têm as suas próprias versões na página CVE do Ubuntu.
- Red Hat: foram disponibilizados kernels corrigidos a 1 de novembro para o RHEL 8 (RHSA-2026:93414), o RHEL 9 (RHSA-2026:93412) e o RHEL 10 (RHSA-2026:93413), com avisos adicionais para os fluxos EUS, SAP e NVIDIA. A 3 de novembro, o kernel-rt do RHEL 9 e as imagens do OpenShift 4 e 5 CoreOS continuavam listados como afetados, enquanto o RHEL 6 e o RHEL 7 não foram afetados.
- Debian, Oracle Linux e SUSE: já foram lançados pacotes corrigidos para, pelo menos, alguns kernels, segundo o The Hacker News.
Compilar o seu próprio kernel. A correção do upstream está disponível 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 do Linux. A equipa CVE do kernel recomenda atualizar para o kernel estável mais recente, em vez de selecionar apenas o patch.
Como o « Aikido » ajuda
AikidoA análise de máquinas virtuais do [nome] deteta a vulnerabilidade CVE-2026-98432 nas suas máquinas virtuais ligadas, com um nível de gravidade base de 9,8. O Aikido ajusta o nível de gravidade por máquina virtual com base na acessibilidade da rede; por isso, utilize a vista de acessibilidade para ver quais as máquinas virtuais a que a Internet tem acesso e aplique as correções nessas máquinas em primeiro lugar.
Se ainda não ligou as suas máquinas virtuais, aceda a «Máquinas virtuais» em Aikido e selecione «Ligar máquinas virtuais». O Aikido é compatível com a AWS, o Azure e o GCP.
A deteção segue os avisos dos fornecedores. Caso um fornecedor ainda não tenha publicado uma correção para o kernel, um host pode estar vulnerável sem que isso seja indicado como afetado; por isso, verifique também o sistema de acompanhamento da sua distribuição. Um host que tenha instalado a atualização, mas ainda não tenha reiniciado, pode aparecer como corrigido; por isso, reinicie primeiro.
Se ainda não for possível aplicar a correção
Estes passos reduzem a exposição. Nenhum deles corrige a falha, pelo que deve aplicar a correção e reiniciar assim que o seu fornecedor disponibilizar um kernel. A AWS refere os dois primeiros como medidas provisórias, enquanto a Red Hat afirma que nenhuma das medidas de mitigação que analisou é fácil de implementar, adequada para a maioria das instalações e estável. Se estiver a executar um servidor Go que não esteja protegido por um equilibrador de carga, utilize a configuração do Go indicada abaixo.
- Desative o MPTCP. Defina net.mptcp.enabled=0. Para programas em Go 1.24 ou versões posteriores, defina GODEBUG=multipathtcp=0. Isto é importante porque a exploração da Anthropic necessitava de um ouvinte MPTCP, e o Go 1.24 e versões posteriores solicitam-nos por predefinição sempre que o kernel permite o MPTCP. Trata-se de uma medida de controlo fraca: a Equipa de Segurança do Go considera que a desativação por programa é frágil, uma vez que um único ouvinte MPTCP exposto continua a deixar o sistema vulnerável. Definir net.mptcp.enabled=0 mantém os sockets MPTCP já abertos, pelo que é necessário reiniciar os serviços afetados posteriormente, de acordo com Marcus Hutchins. Para listar os ouvintes MPTCP, execute o comando sudo ss -Mlnp.
- Rejeitar pacotes IPv4 que transportem opções IP. A AWS fornece esta regra: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. Isto é importante porque a falha reside na forma como o kernel lida com as opções IP armazenadas numa ligação pendente, e o ataque utiliza um SYN que as transporta. No AWS Network Firewall, a AWS publica uma regra com estado equivalente que requer uma ordem rigorosa das regras.
- Coloque o servidor num equilibrador de carga separado ou num serviço gerido que encerre a ligação TCP antes de o tráfego chegar ao seu kernel. Um proxy no mesmo servidor não conta. De qualquer forma, atualize as instâncias que se encontram por trás dele.
Como verificar se a correção já está em vigor
Uma atualização do kernel só entra em vigor após um reinício; por isso, verifique o kernel que está a ser executado, e não o que está instalado.
uname -r
Compare o resultado com a versão corrigida do kernel indicada no aviso do seu fornecedor. Os fornecedores aplicam correções retroativas, pelo que deve utilizar a versão corrigida por eles próprios, em vez da versão do upstream. Se continuar a ser apresentada a versão antiga, significa que o anfitrião ainda não foi reiniciado com o kernel corrigido.
Repete este procedimento em todas as máquinas virtuais, incluindo as que se te tenham escapado e os nós que estão sob os teus contentores.
Quem é afectado
Qualquer servidor Linux que execute o kernel 4.4 ou posterior e que tenha uma porta TCP IPv4 acessível a um atacante. O IPv6 não é afetado pela vulnerabilidade principal. Na AWS, isto abrange instâncias EC2 e Lightsail autogeridas, instâncias ECS no EC2 container e nós EKS. O AWS Lambda não é afetado, uma vez que as funções não expõem portas TCP IPv4 públicas.
O que está à frente do apresentador altera a tua exposição:
- AWS WAF, Application Load Balancer, Classic Load Balancer, ouvintes TLS do Network Load Balancer, CloudFront e API Gateway. A AWS afirma que, quando se seguem as melhores práticas, estes serviços não encaminham ligações TCP provenientes de fontes não confiáveis diretamente para as suas instâncias, e está a aplicar correções à infraestrutura subjacente a esses serviços. Continua, no entanto, a recomendar a atualização das instâncias por trás desses serviços no prazo de 30 dias.
- Listeners TCP do Network Load Balancer e do Global Accelerator. A AWS recomenda aos clientes que atualizem a versão da sua plataforma assim que estiverem disponíveis versões corrigidas.
- Um proxy como o nginx ou o HAProxy no seu próprio servidor Linux. Isto não é uma proteção. O kernel da máquina que aceita a ligação é que gere o handshake TCP, pelo que o servidor proxy também precisa do patch.
No caso dos contentores, o kernel que importa é aquele que se encontra no nó onde estes são executados.
É grave?
Considere isto como urgente para qualquer servidor ligado à Internet. Destacam-se três pormenores:
- Foi demonstrada uma vulnerabilidade que permite o acesso remoto com privilégios de root. A equipa Frontier Red Team da Anthropic afirma que, após um pedido inicial, o Claude criou um exploit que executa comandos com privilégios de root num servidor Linux com um listener MPTCP (Multipath TCP). No teste realizado, a divulgação de um endereço do kernel demorou 48 minutos e a execução do comando demorou mais 5 minutos.
- O atacante pode tentar novamente. Segundo a Anthropic, uma corrida perdida apenas falha nesse específico processo de estabelecimento de ligação e não provoca uma falha no sistema, pelo que um atacante determinado pode continuar a tentar até que consiga.
- Esta condição prévia pode ser mais comum do que parece. Uma aplicação tem de solicitar o MPTCP quando abre um socket e, desde a versão 1.24 do Go, os programas Go fazem isso por predefinição para os sockets em que estão a escutar, de acordo com a Equipa de Segurança do Go. O kernel também tem de permitir o MPTCP, e algumas distribuições, como o AlmaLinux e o CloudLinux, vêm com esta funcionalidade desativada por predefinição. Quando está ativada, um servidor Go pode funcionar como ouvinte sem que ninguém o tenha selecionado.
Algumas questões permanecem em aberto. A Anthropic não divulgou a vulnerabilidade, a versão do kernel nem a configuração que testou, e a equipa do kernel da CloudLinux afirma que não conseguiu reproduzir a alegação. A falha reside no código TCP IPv4 comum, e nem o registo CVE nem a correção do kernel mencionam o MPTCP; por isso, a equipa de segurança da Go afirma que os sistemas sem ouvintes MPTCP podem estar expostos a ataques semelhantes. O boletim da Red Hat indica que o MPTCP não é uma condição necessária para esta falha e que os nós do OpenShift na sua configuração predefinida, com o MPTCP desativado, continuam a ser afetados. Até 2 de novembro, nenhum fornecedor ou CERT tinha relatado ataques em ambiente real. Marcus Hutchins relata que proxies residenciais e servidores VPN sediados na Rússia começaram a sondar a porta 443 através do MPTCP a 2 de novembro, o que ele suspeita estar a fazer uma varredura à procura desta CVE, e a sua própria varredura, realizada a 30 de outubro, encontrou cerca de 2,1 milhões de servidores acessíveis através do MPTCP nessa porta.
A maioria dos fornecedores atribui-lhe uma pontuação inferior à da equipa do kernel, porque consideram que é mais difícil vencer a corrida:
| Fonte | Resultado | O que pressupõe |
|---|---|---|
| Equipa CVE do kernel do Linux (CVSS 3.1) | 9.8 | Ataque à rede sem privilégios nem interação do utilizador, e de baixa complexidade, uma vez que ambos os lados da corrida são induzidos pelo atacante |
| Página da Red Hat sobre o CVE | 9.8 | Tal como a equipa do kernel |
| Vetor CVSS 4.0 listado pelo Ubuntu | 8.3 | Impacto elevado na disponibilidade; impacto reduzido na confidencialidade e na integridade |
| Oracle, SUSE | 8.1 | Tal como a equipa do kernel, mas com elevada complexidade de ataque |
| Amazon | 7.0 | Classificado como «Importante» |
O que é o CVE-2026-98432?
Em termos simples, o kernel pode libertar um bloco de memória enquanto outra CPU ainda o está a ler. Um atacante que controle o momento certo pode aproveitar essa situação para ler ou corromper a memória do kernel, ou provocar uma falha no sistema, de acordo com a equipa CVE do kernel.
Durante um handshake TCP, o cliente envia um pacote SYN e o servidor responde com um SYNACK. O kernel mantém as opções IP do SYN com um marcador de posição para a ligação semiaberta, denominado « socket » de pedido. Na função tcp_v4_syn_recv_sock(), o novo processo filho socket assume a posse dessas opções sem as copiar. Se outra CPU ainda estiver a construir um SYNACK para um SYN retransmitido, as opções podem ser libertadas enquanto ainda estão em uso. Trata-se de um «use-after-free», aqui na função ip_options_build().
O pedido de migração d socket (net.ipv4.tcp_migrate_req=1, ou um programa BPF reuseport migrate) abre um caminho semelhante. A correção do upstream substitui as chamadas a `free` por `kfree_rcu()`, que aguarda até que nenhuma CPU possa ainda estar a ler a memória. O IPv6 evita o primeiro problema porque o kernel copia as opções para as ligações IPv6. Existe um problema de migração semelhante para o IPv6, mas este só se aplica nos casos em que o CALIPSO define opções IPv6, e o kernel está a resolvê-lo num patch separado.
O bug surgiu no Linux 4.4. Os programadores do kernel aplicaram a correção a 5 de outubro, e o CVE foi publicado a 15 de outubro. A correção do kernel atribui o mérito a um investigador da Anthropic por ter comunicado o problema.
