Se você tem um VPS, um servidor com Docker ou qualquer máquina Linux recebendo conexões da internet, pare um minuto: a falha no kernel Linux registrada como CVE-2026-98432 recebeu nota 9,8 de 10 e pode ser explorada à distância, sem senha.
O problema está no código que o Linux executa ao aceitar uma conexão TCP por IPv4, antes de qualquer programa ver essa conexão. A falha foi relatada por um pesquisador da Anthropic, que diz que o modelo Claude escreveu um exploit capaz de rodar comandos como root.
Abaixo, a gente explica o que aconteceu, quem está exposto e como conferir e proteger seu servidor hoje, com base no levantamento detalhado da Atlas Security, atualizado em 1º de novembro de 2026.
O que é a falha no kernel Linux CVE-2026-98432
É um erro do tipo use-after-free, ou “uso depois de liberar”: o sistema devolve um pedaço da memória como livre, mas outra parte do código ainda continua lendo aquele espaço. É como devolver a chave do apartamento enquanto alguém ainda está lá dentro.
Na prática, quando alguém se conecta ao servidor, o kernel guarda temporariamente as opções do cabeçalho IPv4 enviadas por quem conecta. O bug fazia o kernel liberar essa área cedo demais, enquanto outro processador ainda podia usá-la para montar a resposta.
Segundo as notas da autoridade de CVE do próprio kernel, isso pode vazar memória do kernel para o atacante, corromper memória ou derrubar a máquina. A Red Hat diz que um atacante remoto, sem autenticação, poderia chegar à execução remota de código.
| Item | Detalhe |
|---|---|
| Identificador | CVE-2026-98432 |
| Gravidade | Crítica, CVSS 3.1 de 9,8 (kernel e Red Hat) |
| Onde está | Aperto de mão (handshake) TCP no IPv4 |
| Desde quando | Linux 4.4 em diante |
| Quem relatou | Xinyang Ge, da Anthropic |
| Correção | Eric Dumazet, troca de duas chamadas kfree() por kfree_rcu() |
O papel do Claude na descoberta
De acordo com a Anthropic, citada pela Atlas, o Claude escreveu “após um prompt inicial” um exploit que executa comandos arbitrários como root, sem credenciais, em servidores Linux com um listener de multipath TCP (MPTCP). No teste da empresa, levou 48 minutos para vazar um ponteiro do kernel e mais cinco minutos para chegar à execução de comandos.
A Anthropic não publicou o exploit. Mas, até a noite de 1º de novembro, 41 repositórios no GitHub já citavam a CVE, e pelo menos sete diziam incluir um gatilho da condição de corrida ou uma prova de conceito. A falha ainda não constava no catálogo de vulnerabilidades exploradas da CISA.
É mais um sinal de algo que já comentamos aqui: a IA encontra falhas mais rápido do que os times conseguem corrigir. Para quem cuida de servidor, isso significa que a janela entre a correção sair e alguém explorar está ficando curta.
Quem está exposto
Qualquer kernel Linux a partir da versão 4.4 sem a correção, que aceite conexões TCP por IPv4: servidores web, SSH, bancos de dados, balanceadores de carga e nós de Kubernetes. Contêineres usam o kernel da máquina hospedeira, então trocar a imagem do contêiner não resolve.
- Prioridade máxima: máquinas com listener MPTCP, que é o cenário do exploit da Anthropic. Programas em Go abrem esse tipo de listener por padrão desde o Go 1.24, segundo o time de segurança do Go.
- Também em risco: o time do Go alerta que o bug não é específico do MPTCP e que sistemas sem esse listener podem ser vulneráveis a ataques parecidos.
- Fora do problema principal: conexões IPv6, segundo o próprio commit da correção.
Situação das distribuições em 1º de novembro
A correção oficial saiu 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. Mas quase todo servidor usa o kernel da distribuição, que tem numeração própria.
| Distribuição | Status em 1º/11/2026 |
|---|---|
| Debian 12 e 13 | Corrigido |
| RHEL 8, 9 e 10 | Corrigido em 1º de novembro |
| Amazon Linux 2 e 2023 | Corrigido |
| Oracle Linux (kernel UEK) | Corrigido desde 16 de outubro |
| SUSE Enterprise 16.0 e 15 LTSS | Corrigido (15 SP7 em andamento) |
| AlmaLinux 8, 9 e 10 | Correção ainda em teste |
| Ubuntu (todas as versões) | Ainda vulnerável, correção em andamento |
Como verificar e proteger seu servidor
Se você roda um VPS como o que usamos no tutorial de Claude Code 24/7 em um VPS, siga estes passos. Rode os comandos na máquina hospedeira, não dentro de contêineres.
Use
uname -r. No Debian e Ubuntu, liste os pacotes com dpkg -l "linux-image*" | grep ^ii; no RHEL e derivados, use rpm -q kernel. Compare com o status da sua distribuição, não com a versão oficial do kernel.O comando
ss -Mlnp mostra só sockets MPTCP e os processos donos deles. Resultado vazio significa que não há listener MPTCP.Instale o kernel corrigido da sua distribuição e reinicie a máquina. Sem reiniciar, a correção não entra em vigor. Reinicie também hosts de contêiner e nós de Kubernetes.
Red Hat e AlmaLinux publicaram regras de firewall que descartam pacotes TCP IPv4 com opções no cabeçalho. A Red Hat avisa que isso reduz a exposição, mas não elimina o risco. A regra some ao reiniciar.
Com
sudo sysctl -w net.mptcp.enabled=0 e o mesmo valor gravado em /etc/sysctl.d/, novos sockets MPTCP deixam de funcionar. Reinicie os serviços que já tinham listener aberto. Isso remove o cenário do exploit, não o bug.Perguntas frequentes
Meu site na hospedagem compartilhada está em risco?
O kernel é responsabilidade da empresa de hospedagem nesse caso. Vale conferir os avisos de segurança dela, mas não há o que atualizar do seu lado.
Usar Docker me protege?
Não. O contêiner usa o kernel da máquina hospedeira, então é o host que precisa ser atualizado e reiniciado.
Desligar o MPTCP resolve?
Não totalmente. Tira o cenário do exploit publicado pela Anthropic, mas o bug está no TCP IPv4 comum, e o time do Go diz que pode haver ataques parecidos sem MPTCP.
Já existe ataque acontecendo?
Até 1º de novembro, a falha não estava no catálogo de vulnerabilidades exploradas da CISA, mas já havia repositórios públicos dizendo ter prova de conceito. Não espere para atualizar.
Conclusão
A CVE-2026-98432 é o tipo de falha que pede ação hoje: nota 9,8, ataque remoto sem senha e uma correção que só vale depois de reiniciar. Confira seu kernel, atualize e, se a sua distro ainda não corrigiu, aplique a mitigação.
Para entender por que esse ritmo de descobertas está acelerando, leia nosso texto sobre IA encontrando falhas mais rápido do que os times corrigem.