Uma falha no processamento de conexões TCP do kernel Linux, identificada como CVE-2026-98432, ganhou nova dimensão após a Anthropic demonstrar que ela pode ser explorada remotamente para executar comandos com privilégios de root. A demonstração exige condições específicas e não equivale a ataques confirmados contra organizações.
A vulnerabilidade foi divulgada pela equipe de segurança do kernel em 15 de outubro e recebeu pontuação CVSS 3.1 de 9,8 no registro coordenado pelo projeto. O problema afeta o tratamento de opções IPv4 durante a criação e a retransmissão de conexões TCP. A falha de sincronização permite que uma CPU continue utilizando uma estrutura de memória enquanto outra já a liberou, uma condição conhecida como use-after-free.
Para administradores de infraestrutura, a questão não se resume à pontuação. Servidores de aplicações, plataformas em nuvem e equipamentos baseados em Linux podem compartilhar o mesmo subsistema de rede vulnerável, mas o risco depende da versão efetivamente instalada, das correções incorporadas pela distribuição, dos serviços acessíveis e das condições necessárias à exploração. A atualização de uma imagem de contêiner, por exemplo, não corrige automaticamente o kernel do host.
Uma disputa entre CPUs durante o estabelecimento da conexão
Segundo o comunicado técnico do Linux, a função tcp_v4_syn_recv_sock() transfere opções IPv4 de uma solicitação de conexão para um socket recém-criado sem duplicá-las. Ao mesmo tempo, outra CPU pode processar uma retransmissão SYN e ainda precisar dessas opções para montar a resposta SYN-ACK. Se a estrutura for liberada antes do fim dessa leitura, o kernel pode acessar memória que já não lhe pertence.
A correção substitui a liberação imediata por mecanismos de liberação diferida com kfree_rcu(), respeitando o período de leitura protegido por RCU. O comunicado também descreve um caminho relacionado à migração de sockets TCP, inclusive em configurações que utilizam net.ipv4.tcp_migrate_req ou determinados programas BPF. O problema principal descrito para IPv4 não se reproduz da mesma forma em IPv6, embora o aviso registre uma questão separada na migração de opções IPv6.
Claude demonstrou execução como root, mas o cenário testado tem limites
Em pesquisa publicada em 27 de outubro, a Anthropic afirmou que seu modelo Claude desenvolveu um exploit contra servidores Linux com um listener Multipath TCP (MPTCP). A primeira etapa usa a condição de corrida para obter um endereço de memória do kernel e superar o KASLR, mecanismo que embaralha a localização de regiões de memória. Na segunda, a exploração altera um ponteiro de callback e desencadeia a execução de um comando escolhido pelo atacante com privilégios de root.
No experimento relatado, foram necessários 48 minutos para obter o endereço do kernel e outros cinco minutos para alcançar a execução do comando. A Anthropic não publicou o exploit completo nem detalhou a versão exata do kernel e toda a configuração testada. O comunicado oficial da CVE descreve um problema mais amplo no processamento IPv4/TCP; a demonstração de execução remota como root, porém, foi relatada especificamente para um serviço MPTCP. Não há base para concluir que o mesmo resultado esteja demonstrado em qualquer servidor TCP comum.
Por que as avaliações de severidade divergem
A pontuação de 9,8 considera um vetor remoto, sem autenticação ou interação do usuário, e impactos elevados sobre confidencialidade, integridade e disponibilidade. A Red Hat, entretanto, atribui atualmente 5,9 ao risco em seus produtos, classificando a complexidade de ataque como alta e considerando a indisponibilidade o impacto prático demonstrado. A Oracle apresenta avaliação 8,1. Essas diferenças não significam que uma das organizações esteja necessariamente errada: cada avaliação considera premissas de exploração e contexto do produto, que devem ser lidas juntamente com o advisory correspondente.
Até a apuração de 29 de outubro, os comunicados consultados não documentavam exploração ativa dessa CVE em ataques reais. A prova de conceito relatada pela Anthropic confirma a viabilidade técnica no ambiente de pesquisa descrito, não uma campanha criminosa em andamento.
Correções dependem do kernel distribuído, não apenas do número da versão
A equipe do kernel informa correções nas linhas estáveis mantidas, incluindo 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10, além da linha 7.3. Distribuições empresariais frequentemente incorporam correções por backport sem alterar a versão principal do kernel. Por isso, comparar apenas a saída de uname -r com uma versão upstream pode produzir conclusões equivocadas.
Na data da notícia, Debian, Oracle Linux e determinadas versões de SUSE e Amazon Linux já apresentavam pacotes corrigidos, enquanto Ubuntu e Red Hat ainda indicavam pendências para produtos afetados. Como os estados mudam rapidamente, a verificação deve ser feita no rastreador oficial da distribuição e no boletim específico do pacote instalado, inclusive quando o sistema roda em nuvem ou como host de contêineres.
O primeiro trabalho da equipe de segurança é inventariar hosts Linux, identificar versões de kernel e serviços TCP expostos, conferir os boletins dos fornecedores e programar a instalação dos pacotes corrigidos com reinicialização quando necessária. Sistemas com listeners MPTCP acessíveis merecem atenção prioritária por corresponderem ao cenário de exploração demonstrado, sem que isso dispense a análise de outros serviços IPv4/TCP. Onde a correção ainda não existe, reduzir exposição externa e limitar acesso aos serviços são medidas defensivas gerais; desabilitar MPTCP ou bloquear opções IP não deve ser anunciado como mitigação comprovada sem validação técnica e operacional.
O episódio acrescenta uma preocupação às equipes que administram grandes parques Linux: uma falha de concorrência em um componente de rede amplamente compartilhado pode ser difícil de reproduzir em testes tradicionais, mas ainda assim permitir uma cadeia de exploração sofisticada. A resposta mais consistente é combinar inventário confiável, acompanhamento dos advisories, janelas de atualização e monitoramento de disponibilidade, evitando tanto a negligência diante do CVSS quanto a afirmação precipitada de comprometimento generalizado.
Be the first to comment