CVE-2026-98432: Ubuntu e RHEL ainda não têm patch, e um modelo Claude já escreveu o exploit

Os dois fatos sobre a CVE-2026-98432 não se encaixam bem. Trata-se de um use-after-free no handshake TCP IPv4 do kernel do Linux, explorável pela rede sem login e sem interação, e a equipe de CVE do kernel atribuiu a ele uma pontuação de 9,8. Em 30 de outubro de 2026, o Ubuntu não tem nenhuma correção lançada para 22.04, 24.04, 26.04 ou 26.10, e a Red Hat lista o RHEL 8, 9 e 10 como afetados, sem correção e sem mitigação endossada. O segundo fato é que, em 27 de outubro, a Anthropic publicou uma pesquisa dizendo que um modelo Claude ainda não lançado produziu uma prova de conceito funcional para root remoto não autenticado contra um servidor com um listener MPTCP — cerca de 48 minutos para vazar um endereço do kernel e mais cinco para chegar à execução de comandos.

Uma vulnerabilidade que os dois maiores fornecedores de Linux corporativo ainda não conseguem corrigir, com um exploit funcional escrito em parte por uma máquina, não é uma terça-feira de patches rotineira. É o caso que decide se o seu processo de atualização do kernel e a sua política de acesso de agentes têm alguma relação entre si.

O bug, em um parágrafo.

Quando uma conexão TCP está sendo estabelecida, as opções IP anexadas ao pacote de entrada são entregues ao novo socket em vez de copiadas. Se o handshake retransmitir, o pacote pode ser processado em uma CPU diferente daquela que detém o buffer de opções — e essa segunda CPU pode ler memória que a primeira já liberou. Existe uma condição de corrida semelhante no caminho de migração de requisições. O intervalo afetado começa no kernel 4.4, ou seja, a maioria das máquinas que ainda executam um kernel com manutenção. A correção upstream, commit code>e3f33b0a1d89/code>, atrasa a liberação dos buffers de opções até que nenhum outro núcleo possa ainda manter uma referência.

A explorabilidade decorre da mecânica: nenhuma autenticação, nenhuma interação do usuário, um caminho acessível pela rede e uma corrida que pode ser repetida. O próprio resumo da Anthropic sobre por que o PoC é prático é exatamente essa propriedade — uma corrida perdida faz falhar um handshake em vez de derrubar a máquina, então um atacante tenta novamente.

Três fornecedores, três números de gravidade

A divisão da pontuação é a parte que vale a pena internalizar, pois é ela que decide se o seu scanner abre um ticket esta semana.

• Equipe de CVE do Kernel — 9,8, crítica. Acessível pela rede, sem privilégios necessários, sem interação.

• Red Hat — 8.1, Importante. A posição da empresa é que a corrida é difícil de vencer na prática.

• Ubuntu — Alta prioridade, sem pontuação numérica publicada nas páginas verificadas.

A diferença entre 9,8 e 8,1 não é uma discordância sobre o bug; é uma discordância sobre a probabilidade de vencer uma corrida. Ambas são defensáveis, e a diferença importa operacionalmente: um 9,8 com um PoC público é uma emergência, um 8,1 com uma corrida difícil é uma correção agendada. Até que alguém publique números de reprodução em hardware real, a leitura honesta é que a corrida é vencível, já que um modelo de fronteira teria conseguido vencê-la, segundo relatos.

Quem tem uma solução e quem não tem

Em 29–30 de outubro, o cenário é irregular de um modo que pega quem presume que um kernel estável significa um kernel corrigido.

• Debian 12 bookworm — corrigido em 6.1.190-1 via DLA-4841-1.

• Debian 13 trixie — corrigido em 6.12.113-1 via DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — nenhuma correção lançada; trabalho em andamento.

• Ubuntu 16.04, 18.04, 20.04 — vulnerável, sem correção lançada.

• RHEL 8, 9, 10 e OpenShift 4 — afetados, sem correção e sem mitigação endossada pela Red Hat.

• RHEL 6 e 7 — não afetados.

• Amazon Linux 2023 — kernel 6.18 relatado como corrigido; Oracle Linux UEK relatado como corrigido; SUSE informa que algumas versões foram corrigidas e outras ainda estão em testes, sem especificar as versões.

As versões estáveis upstream que contêm a correção são 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3 — que é a lista a conferir em relação à sua própria compilação, caso você compile seu kernel em vez de usar um pacote da distribuição.

Por que o MPTCP continua aparecendo

O bug não é específico do MPTCP, e é aí que boa parte da cobertura se equivoca. A Red Hat trata qualquer serviço TCP alcançável como um possível gatilho. O que o MPTCP fornece é um caminho demonstrado, e o que fornece o tráfego é o Go: a versão 1.24 e posteriores habilita o TCP multipath por padrão para sockets de escuta Linux quando o kernel tem o MPTCP ativado. A equipe de segurança do Go alertou sobre a combinação em 29 de outubro.

Portanto, “desativar o MPTCP” remove o caminho que a Anthropic demonstrou, não a vulnerabilidade. É uma medida provisória defensável, com uma ressalva específica: vale a pena fazer isso em serviços Go hoje, e não substitui um kernel com patch.

As verificações são curtas:

• code>ss -Mltnp/code> — lista os sockets que estão usando MPTCP no momento.

• code>net.mptcp.enabled/code> — se o recurso do kernel está ativado.

• code>net.ipv4.tcp_migrate_req — desativado por padrão; se você o ativou, desative-o novamente.

Especificamente para Go, code>GODEBUG=multipathtcp=0/code> em tempo de execução, ou uma linha code>godebug/code> no code>go.mod/code>, faz com que o binário opte por não usar.

Nenhuma destas é endossada pelo fornecedor. A Red Hat declara claramente que não dispõe de nenhuma mitigação que atenda ao seu próprio padrão, o que é uma frase mais útil do que uma lista de soluções alternativas esperançosas.

O que a Anthropic realmente publicou

A pesquisa é estreita e específica. Um modelo Claude não lançado, ao receber a CVE e um alvo com um listener MPTCP, produziu uma cadeia que vazou um endereço do kernel em cerca de 48 minutos e alcançou a execução de comandos aproximadamente cinco minutos depois. A Anthropic não publicou o exploit e, até 29 de outubro, nem fornecedores nem o registro da CVE haviam relatado ataques no mundo real; a vulnerabilidade não está no catálogo KEV da CISA. Em 30 de outubro, um repositório GitHub de terceiros publicou ferramentas de laboratório para acionamento de race condition e vazamento de memória — um harness de reprodução, sem chegar à execução total de código.

Essa combinação é a parte interessante. A capacidade é demonstrada, a arma é retida, e o detalhe que a possibilita — a propriedade de nova tentativa que transforma uma corrida frágil em uma confiável — está exposto publicamente em prosa. Agora, qualquer pessoa que consiga reproduzir a corrida sabe por que vale a pena persistir nela.

O que fazer esta semana

• Aplique o patch e reinicie onde houver uma correção. Uma correção de kernel instalada mas não reiniciada não é uma correção; verifique com code>uname -r/code>.

• Onde a sua distribuição não tiver patch — Ubuntu 22.04 até 26.10, RHEL 8 até 10 — decida agora se você usará um live patch do fornecedor, migrará para uma versão corrigida ou aceitará a exposição com o MPTCP desativado nos serviços Go.

• Inventarie a exposição a MPTCP em vez de assumir que está desativado. A predefinição mudou no Go, não na sua configuração, e uma alteração a uma predefinição é invisível num diff de configuração.

Ensaiar a reinicialização. Esse tipo de correção exige uma reinicialização completa, e as organizações que perderão mais tempo são aquelas que descobrem sua estratégia de failover durante a janela de manutenção.

As duas perguntas que este CVE realmente suscita

O primeiro diz respeito à geração de exploits, e não é filosófico. Um modelo encontrou uma sequência que muitíssimos pesquisadores humanos não tinham encontrado, num alvo com uma configuração habilitadora específica, em menos de uma hora. Independentemente de o exploit ser publicado ou não, a linha do tempo mudou: a janela entre um comunicado público e um exploit funcional agora é medida em relação a modelos que leem o comunicado.

A segunda questão é sobre o que significa aplicar patches quando os fornecedores não podem corrigir. A distribuição que entrega um kernel e o kernel que contém a correção não são o mesmo objeto, e a lacuna entre eles é exatamente onde essa vulnerabilidade reside para a maioria dos leitores deste post. O OrcaRouter AI Incident Archive indexa incidentes como este em relação às suas fontes primárias, gravidade e confiança, que é a versão desta história que vale a pena manter quando o ciclo de notícias passar.

O que não se deve fazer é classificar isto como “esperar pelo fornecedor”. A própria página do fornecedor diz que ainda não há nada pelo que esperar.

Nota de fontes: o mecanismo, o intervalo afetado a partir do kernel 4.4, o commit upstream code>e3f33b0a1d89/code>, a lista de versões estáveis e as orientações de mitigação provêm do registo da CVE e dos avisos das distribuições lidos em 30 de outubro de 2026. As classificações 9,8, 8,1 e «High» do Ubuntu são, respetivamente, da equipa de CVE do kernel, da Red Hat e da Canonical. O estado dos patches por distribuição provém do DLA-4841-1 e do DSA-6568-1 da Debian, das páginas de CVE da Red Hat e do Ubuntu e das declarações dos fornecedores na mesma data. A cronologia da prova de conceito, os valores de 48 minutos e cinco minutos e a propriedade de nova tentativa são da investigação da Anthropic de 27 de outubro, que reteve o exploit. O repositório de laboratório de 30 de outubro é descrito como sendo de terceiros e não é nosso.