Linux escondeu por 9 anos falha que entrega root milhões de servidores

Uma falha no Linux passou nove anos dentro do kernel sem ser notada. Ela recebeu o apelido de RefluXFS e o identificador CVE-2026-64600. Na prática, qualquer usuário local conseguia virar root em servidores com XFS ativado. Além disso, a exploração funcionava com as proteções padrão ligadas. Portanto, o alerta vale para todo time que mantém infraestrutura corporativa.

Linux e o bug que dormiu no kernel desde 2017

O código vulnerável entrou no kernel em fevereiro de 2017. Desde então, ele seguiu ativo em mais de 16 milhões de sistemas pelo mundo. A equipe de segurança da Qualys localizou o problema apenas agora. Ou seja, quase uma década de janelas abertas passou despercebida pelas auditorias manuais.

O ponto crítico fica na camada de alocação do XFS. Esse é o sistema de gerenciamento de arquivos padrão em boa parte das distribuições voltadas a servidor. Por isso, o alcance foi tão amplo.

Reflink: o recurso silencioso que virou porta de entrada

A falha depende de uma condição de corrida acionada quando a função reflink está ativa. O reflink permite clonar arquivos sem duplicar blocos no disco. Assim, o sistema economiza espaço e ganha velocidade em cópias grandes. Contudo, essa mesma economia abriu espaço para o ataque.

Primeiro, o invasor clona um arquivo do sistema para um diretório próprio. Depois, ele dispara gravações simultâneas na memória. Em seguida, o kernel se confunde e grava a alteração no arquivo original protegido. Arquivos como /etc/passwd e binários do sistema entram nessa conta.

A escrita que sobrevive ao reboot e passa longe dos logs

A modificação vai direto para o disco. Portanto, ela continua válida depois da reinicialização da máquina. Os relatórios de log seguem limpos durante todo o processo. Dessa forma, o time de operações perde o principal sinal de alerta.

Esse detalhe muda a resposta a incidentes. Afinal, um servidor comprometido continua comprometido mesmo após um restart de rotina.

SELinux, KASLR, SMEP e SMAP ficaram fora do jogo

A RefluXFS age abaixo das camadas tradicionais de defesa. Módulos como o SELinux permanecem ativos e ainda assim ficam cegos. O mesmo vale para o isolamento de containers. As proteções de memória KASLR, SMEP e SMAP também seguem sem efeito aqui.

O motivo é simples. A corrupção acontece na lógica do próprio sistema de arquivos. Logo, o ataque dispensa qualquer disputa com as mitigações de userland.

Linux com XFS: as distros que entraram na zona de risco

Red Hat Enterprise Linux, Oracle Linux, Amazon Linux, Fedora, CentOS Stream, Rocky Linux, AlmaLinux e CloudLinux trazem o XFS por padrão em servidores. Todas foram afetadas de forma direta.

Debian, Ubuntu e SUSE adotam outro sistema de arquivos como padrão. Ainda assim, elas ficam expostas quando alguém escolhe o XFS manualmente na instalação. Por isso, vale checar o filesystem real de cada volume antes de dar o caso por encerrado. Uma consulta rápida com o utilitário df já mostra o tipo de sistema de arquivos montado.

Uma IA leu o kernel antes dos atacantes

A descoberta veio de um fluxo híbrido. A Qualys Threat Research Unit integrou o modelo Claude Mythos Preview à auditoria manual de código. O trabalho faz parte do Project Glasswing, da Anthropic.

A tarefa dada ao modelo foi bem específica. Ele deveria procurar condições de corrida parecidas com a antiga Dirty COW. Após rodadas iterativas, a IA apontou o trecho exato do XFS e gerou um teste funcional. Em seguida, os pesquisadores revisaram a lógica, reproduziram a exploração e avisaram os mantenedores do kernel.

Saeed Abbasi, chefe de pesquisa de ameaças da Qualys, resumiu a leitura do caso. Segundo ele, o valor aparece no uso responsável da IA somado ao julgamento humano. Ou seja, o ganho real acontece quando defensores fecham falhas graves antes do abuso.

Linux atualizado hoje: o checklist do time de infra

Os mantenedores do kernel publicaram a correção oficial em 16 de julho. Os fornecedores já distribuem os pacotes corrigidos para as distribuições corporativas. Portanto, a atualização virou prioridade imediata.

No momento, mitigações temporárias de configuração seguem indisponíveis. Em outras palavras, o patch é o único caminho.

1. Primeiro, identifique os volumes que rodam XFS.
2. Depois, confirme se o reflink está ativo nesses volumes.
3. Em seguida, aplique o pacote de kernel corrigido pela sua distribuição.
4. Por fim, reinicie os servidores, já que a proteção entra em vigor apenas após o boot.

O que o RefluXFS ensina sobre código legado

Nove anos de exposição contam uma história sobre revisão de código. Trechos antigos e estáveis recebem menos atenção com o tempo. Enquanto isso, eles continuam no caminho crítico de milhões de máquinas.

A leitura assistida por IA muda essa equação. Modelos processam volumes de código que nenhuma equipe cobre em poucas semanas. Ainda assim, a validação humana continua no centro da decisão.

Para quem escreve ou mantém software de baixo nível, o recado é direto. Concorrência mal tratada segue como uma das fontes mais caras de vulnerabilidade. Por isso, testes de condição de corrida merecem espaço fixo no pipeline.

Acompanhe nosso perfil no Instagram!