Claude desenvolveu um exploit remoto de privilégios de root para uma falha de segurança no TCP do Linux 9.8 que ainda não foi corrigida no RHEL e no Ubuntu

Principais conclusões

• A vulnerabilidade CVE-2026-98432 permite que um invasor remoto provoque uma condição de “use-after-free” durante o handshake TCP IPv4 no Linux.
• A Anthropic afirma que um modelo do Claude ainda não lançado foi transformado em um exploit de root remoto contra ouvintes do MPTCP.
• A Upstream corrigiu o problema em 5 de outubro, mas os kernels baseados no RHEL e o Ubuntu ainda não receberam as correções.
• O Go 1.24 e versões posteriores ativam o MPTCP nos soquetes de escuta por padrão, mas as versões EL 8, 9 e 10 mantêm o MPTCP desativado.

A versão resumida

Ir para a versão completa ↓

O que aconteceu: Em 15 de outubro de 2026, a equipe de CVE do kernel publicou o CVE-2026-98432, uma condição de corrida de acesso após liberação de memória (use-after-free) no código que lida com handshakes TCP IPv4, e atribuiu uma pontuação CVSS de 9,8 em 24 de outubro. A correção de duas linhas foi aplicada no upstream em 5 de outubro e está presente em todos os ramos estáveis mantidos. O pesquisador da Anthropic, Xinyang Ge, relatou a vulnerabilidade. Ir para esta seção →

A alegação: Em 27 de outubro, a Anthropic informou que um modelo interno de pesquisa do Claude, ainda não divulgado, criou uma vulnerabilidade funcional que permite que um invasor remoto, sem credenciais, execute comandos como root em servidores Linux com um listener Multipath TCP (MPTCP). O código da vulnerabilidade, a versão do kernel e a configuração testada não foram divulgados, e até 30 de outubro não havia sido relatada nenhuma reprodução independente pública. Ir para esta seção →

Quem é afetado: Qualquer kernel a partir do Linux 4.4 que ainda não tenha incorporado a correção, em um servidor que aceite conexões TCP IPv4. Isso inclui o RHEL 8, 9 e 10 e as distribuições baseadas neles, além do Ubuntu. O RHEL 7 e o CentOS 7 não são afetados, e as conexões IPv6 não acionam o bug principal. Ir para esta seção →

Por que o MPTCP é importante: os programas em Go compilados com o Go 1.24 ou versões posteriores ativam o MPTCP em seus soquetes de escuta por padrão. No entanto, as versões EL 8, 9 e 10 vêm com o MPTCP desativado; portanto, um host EL padrão não pode abrir um ouvinte MPTCP, a menos que alguém o tenha ativado. A Equipe de Segurança do Go ainda afirma que sistemas sem um ouvinte MPTCP podem estar vulneráveis a ataques semelhantes. Ir para esta seção →

Situação atual: Não se trata de uma vulnerabilidade “zero day”. A correção foi lançada antes da publicação do CVE, a Anthropic ainda não divulgou seu código de exploração e, até 30 de outubro, não foram relatados casos de exploração em ambiente real, além de o bug não constar no catálogo KEV da CISA. O Debian, o Oracle UEK, a maioria das versões suportadas do SUSE e alguns kernels do Amazon Linux já estão corrigidos. A Red Hat e o Ubuntu ainda não lançaram um kernel corrigido e não informaram uma data. O patch sem reinicialização da KernelCare já está disponível para o Debian 13, e os patches para o EL 8, 9 e 10 estão sendo desenvolvidos sem esperar pela Red Hat. Ir para esta seção →

O que fazer hoje: Descubra se há algum serviço em seus servidores que esteja escutando no MPTCP. Com -H Se desconsiderarmos a linha de cabeçalho, cada linha exibida por este comando corresponde a um listener MPTCP:

ss -H -lMn

Em hosts sem kernel fixo, descartar pacotes TCP de entrada que contenham opções IP deve bloquear o gatilho documentado, independentemente de haver MPTCP ou não. Isso ainda não foi testado, portanto, experimente primeiro no ambiente de teste. Ir para esta seção →

A maioria dos bugs do kernel acessíveis pela rede tem uma condição específica. É preciso carregar um módulo, ativar um protocolo específico ou ter um serviço em execução que quase ninguém usa. O CVE-2026-98432 está no código que aceita conexões TCP IPv4. Se um servidor aceita conexões TCP IPv4, ele executa esse código.

Só isso já faria com que um CVE 9.8 merecesse atenção. O que o levou às manchetes foi a afirmação da Anthropic de que um de seus modelos o transformou em uma vulnerabilidade de acesso root remoto, sem a necessidade de credenciais. O próprio CVE havia sido divulgado discretamente doze dias antes, um dos muitos que a equipe de CVE do kernel publica todas as semanas.

O problema está no cronograma. A Upstream corrigiu isso em 5 de outubro. O Debian lançou um kernel corrigido até 16 de outubro. A Red Hat ainda não disponibilizou nenhuma versão para o RHEL 8, 9 ou 10, e essa lacuna, mais do que a questão da IA, determina por quanto tempo os sistemas corporativos afetados permanecerão expostos.

O gatilho é um pacote TCP SYN que contém opções IPv4, especificamente Registrar rota ou data e hora. O tráfego normal quase nunca envia esses dados, mas nada impede que um cliente o faça. O kernel em escuta salva essas opções junto com a solicitação de conexão pendente, em ireq_opt.

Quando o handshake for concluído, tcp_v4_syn_recv_sock() passa as opções para o novo soquete filho sem criar uma cópia, de modo que o soquete de solicitação e o soquete filho agora apontam para a mesma memória. Se o cliente reenviar seu SYN no momento certo, outra CPU poderá captar esse SYN retransmitido e começar a construir um SYNACK a partir das mesmas opções em ip_options_build(). Se o soquete filho for encerrado nesse meio tempo, inet_sock_destruct() libera as opções com um simples kfree(), e o caminho do SYNACK lê a memória que já não existe mais.

O bug remonta ao commit 079096f103fa (“tcp/dccp: inserir solicitações syn_recv na tabela ehash”), o que permite que os soquetes de solicitação sejam processados sem manter o bloqueio do ouvinte. Esse commit foi lançado no Linux 4.4 em janeiro de 2016. A Red Hat indica que o RHEL 7 não foi afetado, e o CentOS 7 utiliza a mesma versão do kernel.

O corrigir A correção de Eric Dumazet é praticamente a menor que se pode encontrar no kernel. Uma kfree() em inet_sock_destruct() em net/ipv4/af_inet.c e um em tcp_v4_reqsk_destructor() em net/ipv4/tcp_ipv4.c tornar-se kfree_rcu(), de modo que qualquer processo que ainda esteja lendo as opções seja concluído antes que a memória seja liberada. O primeiro é o comando `free` que causa o problema no caminho principal, e o segundo abrange o caminho de migração abaixo.

Existe uma segunda maneira, mais restrita, de realizar a migração de soquetes de solicitação, que se aplica apenas a net.ipv4.tcp_migrate_req=1 ou um BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programa em anexo. Ambos estão desativados por padrão. Se você leu que esse bug “requer uma configuração diferente da padrão”, isso só se aplica ao caminho de migração. O caminho principal não requer nenhuma configuração.

O IPv6 evita o caminho principal porque tcp_v6_syn_recv_sock() copia as opções. O Registro CVE também aponta um problema de migração semelhante no âmbito do IPv6, limitado às opções definidas pelo CALIPSO, e o desenvolvedor original planeja um patch separado para esse caso.

É difícil vencer essa corrida, mas isso não é tão tranquilizador quanto parece. Uma corrida perdida significa apenas que aquele único aperto de mão falhou. Isso não derruba o servidor, então um invasor pode continuar tentando enquanto a porta permanecer aberta.

A Anthropic descreveu a vulnerabilidade em uma publicação de 27 de outubro da sua equipe Frontier Red Team, juntamente com cadeias de exploração para o Chrome, Safari, Android e Windows. A publicação afirma que o trabalho utilizou um modelo de pesquisa interno ainda não divulgado e que o modelo criou a vulnerabilidade para o Linux após um “estímulo inicial”.

A Anthropic descreve duas etapas. Primeiro, vencer a corrida faz com que o kernel leia um campo de comprimento controlado pelo invasor e copie bytes extras no SYNACK que ele envia de volta; e, assim que uma dessas respostas contiver um ponteiro do kernel, o KASLR é contornado. Em segundo lugar, o mesmo bug causa um estouro de buffer e sobrescreve um ponteiro de retorno de chamada com o endereço de uma carga útil já preparada na memória do kernel. Quando o kernel chama esse ponteiro sobrescrito, um comando shell escolhido pelo invasor é executado como root. A Anthropic afirma que o vazamento de endereço levou 48 minutos em seu teste, e a execução do comando levou mais cinco.

A TuxCare não conseguiu reproduzir a vulnerabilidade, e até 30 de outubro não havia sido divulgada nenhuma reprodução independente e pública. A Anthropic não divulgou o código, a versão do kernel nem a configuração que testou. A publicação também não informa se servidores sem um listener MPTCP podem ser comprometidos da mesma forma.

No entanto, essa afirmação não está em desacordo com o que a equipe do kernel do CVE já havia escrito. As próprias notas de classificação da equipe no registro do CVE descrevem como as opções desatualizadas vazam memória adjacente da pilha do kernel de volta para o par e direcionam gravações fora dos limites do kernel. A cadeia de exploração da Anthropic é basicamente essa descrição colocada em prática.

O MPTCP permite que uma conexão utilize vários caminhos de rede ao mesmo tempo. No Linux, um aplicativo só tem acesso a ele se solicitar ao abrir um soquete; por isso, durante anos, a maioria das equipes podia presumir com segurança que não o estava executando.

O Go mudou isso. Desde a versão 1.24 do Go, os programas em Go no Linux habilitam o MPTCP em soquetes de escuta por padrão, nos casos em que o kernel oferece suporte a essa funcionalidade. Um gateway de API, um proxy reverso ou um serviço interno baseado em Go, desenvolvido com o Go 1.24 ou versões posteriores, pode estar mantendo um ouvinte MPTCP que seus proprietários nunca solicitaram.

As lojas de EL recebem boas notícias aqui. Red Hat fornece o RHEL com o suporte a MPTCP desativado, e as compilações são enviadas da mesma forma; portanto, ativá-la significa definir net.mptcp.enabled=1 Você mesmo. Em um servidor EL 8, 9 ou 10 padrão, um serviço Go solicita MPTCP, o kernel recusa, e o serviço recorre discretamente a um ouvinte TCP simples. A menos que alguém da sua equipe tenha ativado o MPTCP, a cadeia demonstrada pela Anthropic não tem nada a que se direcionar.

No dia 29 de outubro, o Equipe de Segurança da Go essa configuração GODEBUG=multipathtcp=0 no ambiente de um programa desativa essa configuração padrão em tempo de execução, e adicionar godebug multipathtcp=0 para o módulo principal go.mod faz o mesmo durante a compilação. O código que chama SetMultipathTCP em um net.ListenConfig ou net.Dialer anula ambas. A equipe também classificou essa medida como uma mitigação frágil, já que um único ouvinte MPTCP deixado exposto ainda deixa o sistema vulnerável. E foi um passo além. O bug subjacente não é específico do MPTCP, e sistemas sem ouvintes MPTCP podem estar vulneráveis a ataques semelhantes.

De qualquer forma, planeje-se levando em conta esse último ponto. Ninguém demonstrou publicamente ter obtido acesso root em um servidor sem um ouvinte MPTCP, e a cadeia de exploração demonstrada precisa de um. Mas o próprio bug pode ser acessado por meio de qualquer ouvinte TCP IPv4, e a equipe do Go não descarta outras vias; portanto, um host com o MPTCP desativado está menos exposto, mas não está totalmente protegido.

Se sysctl net.mptcp.enabled retornos 1, os aplicativos nesse host podem abrir soquetes MPTCP. Nas versões EL 8, 9 e 10, 0 é a configuração padrão. Em uma versão razoavelmente recente do iproute2, ss -H -lMn lista os ouvintes MPTCP que realmente existem, sem a linha de cabeçalho. Se ss rejeita o -M flag: o iproute2 desse host está muito desatualizado para essa verificação.

Por que os fornecedores não conseguem chegar a um acordo sobre uma pontuação

A equipe do kernel responsável pelo CVE atribuiu à vulnerabilidade CVE-2026-98432 uma pontuação de 9,8, com vetor de ataque de rede, sem privilégios e baixa complexidade de ataque. O raciocínio é que ambos os lados da corrida são “induzidos pelo invasor”, uma vez que o invasor controla o SYN, a retransmissão e o encerramento da conexão. A página do Ubuntu apresenta a mesma pontuação de 9,8. O NVD ainda não havia adicionado sua própria pontuação até 30 de outubro.

A Red Hat começou com uma classificação bem mais baixa. Sua página do CVE classificou inicialmente a vulnerabilidade como “Moderada” (5,9), com uma falha no sistema como o resultado mais provável e sem impacto comprovado na confidencialidade ou na integridade. Em 29 de outubro, seu arquivo de aviso legível por máquina passou para “Importante” (8,1), com alto impacto na confidencialidade e na integridade, e, em 30 de outubro, a página do CVE já exibia a mesma classificação de 8,1. A Oracle, a SUSE e a Amazon também atribuíram a classificação de 8,1.

Toda essa diferença restante se resume a um único indicador. O vetor 8.1 compartilhado pela Red Hat, Oracle, SUSE e Amazon coincide com o da equipe do kernel em todos os aspectos, exceto na complexidade do ataque, que esses fornecedores classificam como alta. Esse é um argumento técnico válido sobre uma competição. Isso importa menos quando perder a competição não custa ao invasor nada além de uma tentativa de conexão.

O problema prático está nas ferramentas. Se o seu scanner ou patch SLA se basear na classificação de gravidade do fornecedor, essa falha pode ter sido exibida nos hosts EL como “Moderada” — ou até mesmo como nada urgente — durante a maior parte do mês de outubro, apesar de uma cadeia de acesso remoto ter sido descrita publicamente. Se o seu processo classifica os patches de acordo com a gravidade do fornecedor, anule essa classificação para este CVE.

O CloudLinux 9 e 10 utilizam kernels do AlmaLinux, portanto seguem a linha do AlmaLinux. A Red Hat menciona o problema para o RHEL 8, 9 e 10, mas não informa uma data de lançamento, e o Ubuntu também não fornece essa informação.

Se você compila seus próprios kernels, a correção está disponível nas versões estáveis mencionadas acima. A equipe do CVE do kernel recomenda migrar para o kernel estável mais recente, em vez de selecionar correções individuais.

Até 30 de outubro, a Red Hat afirma que nenhuma medida de mitigação disponível atende aos seus padrões, e nenhum outro aviso de fornecedor menciona uma. As opções abaixo decorrem da forma como a falha funciona, mas nenhuma delas foi testada internamente contra um ataque. Teste cada uma delas primeiro em um servidor de teste e não considere nenhuma delas como substituto para um kernel corrigido.

A opção com maior alcance é descartar pacotes TCP de entrada que contenham opções IPv4. O caminho principal precisa de opções IP no SYN; o tráfego TCP normal não as contém, e essa regra não leva em conta se algum processo no host utiliza MPTCP:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop

Para desfazer a ação, execute nft delete table ip cve_2026_98432. A regra não é mantida após uma reinicialização; portanto, adicione-a à sua configuração persistente do firewall caso decida mantê-la. A filtragem de opções IP na borda da rede pode abranger todos os hosts atrás dela, desde que todo o tráfego destinado a esses hosts realmente passe por essa borda. O custo é que qualquer cliente TCP que envie opções IP será bloqueado, e esse tipo de tráfego é raro.

Os engenheiros da TuxCare analisaram a regra, e ela parece correta. No entanto, como não há nenhuma prova de conceito pública para testá-la, ainda não há nada com que se possa testá-la.

Em segundo lugar, confirme se o caminho de migração está fechado. sysctl net.ipv4.tcp_migrate_req deveria retornar 0, que é a configuração padrão, e o host não deve ter um BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programa em anexo.

Em terceiro lugar, e como solução mais rápida, desative o MPTCP em qualquer host que não precise dele. Execute sysctl -w net.mptcp.enabled=0, e coloque net.mptcp.enabled = 0 em um arquivo localizado em /etc/sysctl.d/ para que permaneça assim. As versões EL 8, 9 e 10 já são fornecidas dessa forma, portanto isso se aplica principalmente às distribuições que mantêm o padrão do upstream de 1, e em servidores EL nos quais alguém ativou o MPTCP. Reinicie os serviços que já abriram ouvintes MPTCP para que voltem a usar o TCP padrão. Para serviços em Go, GODEBUG=multipathtcp=0 faz o mesmo para cada programa. Isso elimina a necessidade da cadeia do ouvinte Anthropic, mas não corrige o bug.

Se um servidor estiver conectado à Internet e não tiver um kernel fixo, comece verificando net.mptcp.enabled e desativar o MPTCP se não houver necessidade. Trata-se de um único sysctl, fácil de reverter, e que remove o listener do qual a cadeia demonstrada depende. A regra de opções IP é a próxima camada a ser avaliada. Teste-a no ambiente de teste, confirme se ela elimina o que você espera sem causar problemas e, então, decida se vai implementá-la. De qualquer forma, coloque o host na frente da fila para receber um kernel corrigido. Se a sua distribuição já vier com um kernel corrigido, instale-o, reinicie o sistema ou aplique o patch que dispensa a reinicialização e ignore as soluções alternativas.

Verificando um servidor em menos de um minuto

Cinco comandos respondem à maioria das perguntas:

uname -r
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -H -lMn
nft list table ip cve_2026_98432
kcarectl --patch-info | grep 'CVE-2026-98432'

A primeira linha mostra o kernel em execução, mas os kernels do EL e do Ubuntu contêm backports que o número da versão não revela; portanto, compare o pacote do kernel instalado com o comunicado do seu fornecedor e com a tabela acima. A 1 para net.mptcp.enabled isso significa que os aplicativos podem abrir soquetes MPTCP, e net.ipv4.tcp_migrate_req deveria ser 0, o padrão. Cada linha ss -H -lMn O prints é um ouvinte MPTCP. O nft Essa linha exibe a tabela e suas regras, caso estejam carregadas, para que você possa confirmar se a regra de exclusão realmente está presente; e a última linha mostra se o KernelCare aplicou seu patch sem reinicialização para essa CVE. Esses são indicadores rápidos, não um teste de segurança completo. Para uma frota, execute as mesmas linhas por meio do que já lida com seus comandos ad hoc, seja o Ansible, o Salt ou o ssh simples em um loop.

A posição da KernelCare

O patch sem reinicialização da KernelCare para o CVE-2026-98432 já está disponível para o Debian 13, tanto no feed de produção quanto no ePortal. Os patches para o Debian 12 e o Oracle Linux UEK estão em desenvolvimento. A correção do desenvolvedor original é pequena e não altera nenhuma estrutura de dados; por isso, a TuxCare não está aguardando a Red Hat. Os patches que não exigem reinicialização para os kernels EL 8, 9 e 10 no RHEL, AlmaLinux, CloudLinux, Oracle Linux RHCK e Rocky Linux estão sendo compilados neste momento, e o CVE Tracker os exibirá assim que forem lançados. Os patches para o Ubuntu ainda não estão disponíveis, e não há uma data prevista para o lançamento.

No Debian 13, os servidores com atualizações automáticas do KernelCare recebem o patch de acordo com sua programação normal; caso contrário, você pode baixá-lo imediatamente com kcarectl --update. Não é necessário reiniciar. Confirme se a instalação foi bem-sucedida com kcarectl --patch-info | grep 'CVE-2026-98432'. O Rastreador de CVEs do TuxCare mostra o status dos patches que não exigem reinicialização por distribuição, à medida que ele muda.

Adquira o KernelCare hoje mesmo →

A solução veio primeiro, mas ainda não é suficiente

Pelos padrões habituais, essa divulgação ocorreu sem problemas, mas ainda há muitos servidores Linux corporativos aguardando.

A divulgação coordenada cumpriu seu papel nas etapas iniciais. A correção foi lançada antes da publicação do CVE, o CVE foi divulgado antes que alguém reivindicasse uma exploração, e o próprio código de exploração permaneceu confidencial. Ninguém pode chamar isso de “zero day”.

Nada disso ajuda um servidor web RHEL 9 com a porta 443 aberta. Uma correção de duas linhas no upstream ainda precisa se tornar uma compilação do kernel do fornecedor, depois um pacote distribuído e, por fim, um patch que exija ou não reinicialização em cada host exposto. Para o RHEL e as distribuições que o recompilam, essa primeira etapa ainda não havia ocorrido até 30 de outubro. Enquanto isso, um artigo público agora descreve a estrutura de uma cadeia funcional e quanto tempo cada etapa levou. O código permaneceu privado, mas a abordagem não, e a próxima tentativa não precisa começar do zero.

Portanto, verifique quais hosts possuem listeners MPTCP, especialmente aqueles escritos em Go, e desative o MPTCP sempre que não for necessário. Teste a regra de opções de IP no ambiente de teste e, se ela funcionar corretamente, considere aplicá-la aos servidores expostos à Internet que não possuam um kernel fixo. Em seguida, fique atento aos kernels fixos disponibilizados pela sua distribuição e avalie com que rapidez você pode implementá-los em todos os hosts expostos — seja por meio de um patch sem reinicialização ou por reinicialização, dependendo do que sua infraestrutura realmente tolerar.

Adquira o KernelCare hoje mesmo →

Fontes

As fontes primárias para esta publicação são o anúncio do CVE do kernel, o registro do CVE e a correção do upstream, além das páginas dos fornecedores Red Hat (incluindo seu arquivo de aviso e rastreador de bugs), Ubuntu, Debian, Oracle, Amazon e SUSE. Também são citadas a publicação da Anthropic, o anúncio da Equipe de Segurança do Go, a documentação GODEBUG do Go, a documentação do MPTCP do kernel, a entrada no NVD, a cobertura do The Hacker News e os registros de lançamento do KernelCare da TuxCare até 30 de outubro de 2026.