Falha grave no Linux: o que sua empresa precisa fazer agora, mesmo usando containers

Toda empresa que tem um sistema rodando na internet tem, quase com certeza, um servidor Linux por trás. Pode ser na AWS, no Google Cloud, num data center próprio ou escondido dentro de um container. E é exatamente esse pedaço que entrou na lista de prioridades das equipes de tecnologia nas últimas semanas. Se você toma decisões sobre tecnologia na sua empresa, ou escreve o código que roda nesses servidores, este texto explica o que aconteceu e o que perguntar ao seu time.

Um defeito antigo no coração do Linux

O Linux tem um "coração", o kernel, que cuida de tudo que o sistema faz, inclusive receber as conexões que chegam pela internet. Pesquisadores encontraram um defeito justamente nessa parte: um jeito de mandar conexões montadas com cuidado para confundir o kernel e fazer com que ele use um pedaço de memória que já tinha jogado fora. Quem consegue controlar o que vai parar nesse pedaço de memória consegue, em certas condições, assumir o controle da máquina.

O mais incômodo é o tempo. Segundo a análise da TuxCare, o defeito está no código desde 2016. Ou seja, praticamente todo servidor Linux em uso hoje tem esse problema até receber a correção.

A falha ganhou o nome técnico de CVE-2026-98432 e nota 9,8 numa escala de gravidade que vai até 10, de acordo com a Red Hat. A nota é alta por três motivos simples: o ataque vem de fora, pela rede; não precisa de senha; e ninguém do seu lado precisa clicar em nada.

Quem encontrou foi uma IA

Aqui a história fica mais interessante. A falha foi relatada por um pesquisador da Anthropic, e a empresa contou num texto publicado no fim de outubro que um modelo de inteligência artificial interno conseguiu escrever, sozinho, um programa capaz de explorar o defeito. No teste deles, o ataque completo levou menos de uma hora.

O código desse ataque não foi divulgado, e até agora não há relato de alguém usando a falha de verdade. Mas o episódio mostra uma mudança que vale para qualquer empresa de software: o tempo entre "a correção saiu" e "alguém já sabe atacar quem não corrigiu" está ficando menor. Antes, transformar uma falha em ataque exigia semanas de trabalho de um especialista. Agora, uma ferramenta pode fazer boa parte disso.

"Mas a gente usa containers"

Essa é a dúvida que mais aparece, e a resposta pega muita gente de surpresa: containers não te protegem aqui. Um container é como um apartamento num prédio. Cada um tem sua porta, sua mobília, seu jeito. Mas todos dividem a mesma fundação, e o kernel é a fundação.

Por isso, atualizar a imagem Docker da sua aplicação não resolve nada. Quem precisa ser atualizado é o servidor que hospeda os containers. Se vocês usam Kubernetes, isso significa os nós do cluster, inclusive em serviços gerenciados como EKS, GKE ou AKS.

Outra ideia que circulou e não se sustenta: desligar um recurso chamado MPTCP, que foi o caminho usado na demonstração da Anthropic. A própria Red Hat avisa que servidores com esse recurso desligado continuam vulneráveis. Ajuda a reduzir o risco, mas não fecha a porta.

O conserto é simples, a parte difícil é saber onde aplicar

A boa notícia é que a correção já existe e não exige mudar uma linha do código da sua aplicação. Basta instalar a versão nova do kernel e reiniciar o servidor. As principais distribuições estão liberando suas atualizações em ritmos diferentes: na central de segurança da AWS, o Amazon Linux já aparece corrigido, enquanto a página do Ubuntu ainda mostra as versões de suporte longo com a correção a caminho.

Se você não é quem vai fazer o trabalho, estas são as quatro perguntas que vale levar para o seu time esta semana:

• Sabemos quais servidores temos e quais estão expostos à internet? Esse é o ponto de partida. Comece pelos que recebem tráfego de fora.
• A correção da nossa distribuição já saiu? Se sim, a resposta é atualizar e reiniciar. Atualizar sem reiniciar não adianta.
• Se ainda não saiu, o que fizemos enquanto isso? Red Hat e Ubuntu publicaram uma regra de firewall provisória que bloqueia o tipo de conexão usado no ataque. Ela reduz o risco, mas precisa ser testada antes, porque pode atrapalhar alguns sistemas.
• Conseguimos reiniciar servidores sem tirar o sistema do ar? Se a resposta for "não" ou "não sei", esse é o problema real, e ele vai voltar na próxima falha.

Como a gente cuida disso no dia a dia

Na PureCode IT, aviso de segurança vira primeiro uma pergunta de inventário: em quais ambientes isso existe? Nos projetos que desenvolvemos e mantemos, a atualização passa pelo mesmo caminho de qualquer mudança, primeiro em homologação e depois em produção, e os servidores de produção ficam atrás de um balanceador. Assim dá para reiniciar um de cada vez enquanto o outro segura o tráfego, sem ninguém do outro lado perceber. Quando nossos engenheiros trabalham dentro do time de outra empresa, o papel deles é chegar ao time de infraestrutura com o levantamento já pronto, em vez de só repassar a notícia.

A lição vai além desta falha

Daqui a alguns meses, ninguém vai lembrar do número desta CVE. Mas outras como ela vão aparecer, e provavelmente mais rápido, agora que a inteligência artificial também está do lado de quem procura falhas. As empresas que passam por isso sem susto não são as que têm a melhor ferramenta de segurança. São as que sabem responder em poucos minutos onde estão seus servidores e conseguem atualizá-los numa terça-feira qualquer, sem reunião de emergência.