Uma vulnerabilidade crítica no kernel Linux voltou a colocar os administradores de servidores em alerta. Catalogada como CVE-2026-98432, a falha envolve o processamento de conexões TCP e pode levar a execução remota de comandos como root sob condições específicas. Pesquisadores da Anthropic demonstraram um ataque em laboratório contra servidores com listeners Multipath TCP (MPTCP), e a equipe do kernel atribuiu severidade 9,8 numa escala de dez. Isso não significa que todo servidor Linux esteja sendo invadido, mas justifica atenção imediata aos avisos das distribuições.
A investigação divulgada em 30 de outubro de 2026 descreve uma condição de corrida ligada ao uso de memória após sua liberação. O MPTCP permite usar diferentes caminhos de rede numa mesma conexão, característica aproveitada em ambientes com múltiplos links. Há uma distinção indispensável: a falha também envolve TCP comum, mas a exploração remota como root foi demonstrada publicamente em contexto específico de MPTCP. Até o material consultado, não havia relatos confirmados de uso criminoso da CVE em ataques reais.
Da exposição à correção
Serviços e listeners MPTCP realmente usados.
Versão e boletim da própria distribuição.
Patch em janela de manutenção.
Reinicialização e funcionamento dos serviços.
Por que o MPTCP pode ampliar a exposição
Multipath TCP permite que uma sessão aproveite múltiplas rotas disponíveis para melhorar resiliência e continuidade. Uma conexão móvel, por exemplo, pode transitar entre redes sem abandonar toda a comunicação. No entanto, serviços nem sempre deixam claro ao administrador quando esse recurso foi ativado. A cobertura da vulnerabilidade cita o comportamento de versões recentes de Go, que podem aproveitar MPTCP em listeners TCP quando o sistema oferece suporte.
O problema técnico está em estruturas temporárias empregadas durante a negociação de conexões. Em determinadas situações concorrentes, o kernel pode acessar dados cuja vida útil já terminou. Erros dessa classe são difíceis de explorar de maneira estável, mas também podem ter consequências graves. A Anthropic relatou que um modelo experimental ajudou a construir uma exploração que superou mecanismos de proteção do kernel em laboratório.
Distribuições não publicam correções ao mesmo tempo
O código principal do kernel recebeu correção e fornecedores trabalham em pacotes próprios, frequentemente retroportando mudanças para versões mantidas por muitos anos. Por isso, o número mostrado por uname não basta para determinar vulnerabilidade; é necessário consultar o boletim exato da distribuição e o pacote instalado. Debian já havia publicado versões corrigidas para ramos recentes, enquanto avisos de Ubuntu e Red Hat ainda indicavam etapas de atualização em andamento na data da reportagem. O panorama pode mudar rapidamente após novos boletins.
Um servidor que executa kernel fornecido pela distribuição também não deve receber, por impulso, um pacote genérico de outra origem. A atualização precisa respeitar módulos, suporte e janela de manutenção. Em ambientes com serviços críticos, convém validar reinicialização, backups e persistência de conexões. A ação prioritária é inventariar hosts expostos, conferir regras de firewall e acompanhar o fornecedor.
Resposta à CVE-2026-98432
Roteiro para triagem de serviços afetados — não é prova de que um servidor tenha sido explorado.
Inventário
Mapear kernels e serviços expostos que usam MPTCP.
Boletins
Conferir correções disponibilizadas pela distribuição instalada.
Atualização
Aplicar patches testados, backup e reinicialização planejada.
Monitoramento
Revisar logs e alertas sem presumir invasão pela CVE existir.
Como agir sem interromper a produção às cegas
Administradores devem começar pelos serviços que aceitam conexões de redes não confiáveis, especialmente quando usam componentes de rede avançados. A existência de uma prova de conceito não dispensa avaliação de acessibilidade e da versão real do kernel. Se o fornecedor ainda não disponibilizou atualização, restrições de origem de tráfego podem reduzir a superfície de exposição. Alterações em regras de pacotes precisam ser testadas para não bloquear aplicações legítimas; filtros específicos devem seguir a documentação do fabricante, não comandos copiados sem contexto.
A descoberta também reacende a discussão sobre processos de atualização em infraestrutura. Muitas organizações mantêm sistemas aparentemente estáveis por longos períodos, mas esquecem de revisar o estado dos pacotes de segurança. O trabalho preventivo costuma ser menos dramático que uma exploração: registro de versões, cronograma de manutenção e rollback recuperável. Para o leitor técnico, a notícia mais importante não é a criatividade da exploração demonstrada, e sim a necessidade de transformar um alerta crítico em verificação responsável e documentada.
