RefluXFS CVE-2026-64600: falha no kernel Linux e CloudLinux permite root

RefluXFS, identificada como CVE-2026-64600, é uma falha de elevação local de privilégio no filesystem XFS. Um usuário sem privilégios pode explorar uma corrida na implementação de reflink/copy-on-write para sobrescrever o conteúdo em disco de um arquivo que consegue ler — inclusive arquivos root ou binários SUID — e chegar a controle administrativo total.

O que aconteceu

O reflink cria uma cópia lógica que inicialmente compartilha blocos com o arquivo original. Quando uma das cópias recebe uma gravação, o XFS deveria separar os blocos por copy-on-write. A Qualys identificou uma janela de corrida durante gravações diretas concorrentes: depois de soltar e recuperar um lock, o kernel podia usar um mapeamento físico antigo e gravar no bloco que já pertencia somente ao arquivo original.

A alteração ocorre na camada de blocos, persiste após reinicialização e pode não alterar metadados esperados, como proprietário, modo ou horário do inode. Isso torna a falha perigosa para servidores multiusuário: comprometer primeiro um site ou processo restrito pode fornecer a presença local necessária, e RefluXFS pode ser o segundo estágio até root.

Condições necessárias para estar vulnerável

As três condições precisam estar presentes:

1. kernel 4.11 ou posterior sem a correção/backport;
2. filesystem XFS criado com reflink=1;
3. no mesmo XFS, um arquivo sensível legível e um diretório onde o usuário local consiga escrever.

CloudLinux 8, 9 e 10 são relevantes porque instalações novas normalmente usam XFS com reflink. CloudLinux 7 tradicional com kernel 3.10 não possui o código introduzido no 4.11 e não é afetado por essa rota. CloudLinux para Ubuntu 22.04 usa normalmente ext4 e não é afetado por padrão, mas passa a ser relevante se houver XFS reflink montado.

Versões corrigidas no ecossistema CloudLinux

Esses eram os mínimos publicados no rastreador do fornecedor. Instale o kernel estável mais recente disponível hoje. Para KernelCare, confirme se o patch existe no feed da versão em uso; a simples presença do agente não garante cobertura daquele kernel/CVE.

Nível de risco

Crítico em servidores compartilhados ou com usuários locais não confiáveis. A falha não é explorada diretamente pela rede: o atacante precisa executar código local sem privilégios. Porém, em hospedagem, uma vulnerabilidade de plugin, credencial FTP vazada ou shell web pode fornecer exatamente esse primeiro acesso. O salto para root elimina o isolamento entre sites e contas.

Como verificar sem explorar

Identifique sistema, kernel em execução e filesystems:

cat /etc/os-release
uname -r
findmnt -t xfs -o TARGET,SOURCE,FSTYPE,OPTIONS
xfs_info / 2>/dev/null | grep -o 'reflink=[01]'

Repita xfs_info para cada ponto XFS. Depois compare o pacote instalado e o kernel iniciado:

rpm -q kernel kernel-core 2>/dev/null
grubby --default-kernel 2>/dev/null
kcarectl --uname 2>/dev/null
kcarectl --patch-info 2>/dev/null | grep -i 'CVE-2026-64600'

• reflink=0 ou raiz não XFS: essa montagem não oferece a rota descrita;
• reflink=1 e kernel abaixo do mínimo, sem backport/live patch confirmado: vulnerável;
• kernel instalado corrigido, mas uname -r ainda mostra o anterior: falta reiniciar;
• KernelCare mostra cobertura explícita: o kernel em memória pode estar corrigido mesmo mantendo o número original.

Correção e resposta

A correção definitiva é instalar o kernel do fornecedor e reiniciar, ou aplicar um live patch explicitamente compatível. O CloudLinux informou que não há workaround confiável baseado apenas em mount option, bits SUID ou layout. Em CL9/CL10, a atualização típica é dnf update 'kernel*', seguida de reinicialização planejada; confirme sempre os canais do fornecedor para o branch usado.

Medidas adotadas pela WebinHost

Este tipo de falha ilustra por que o tempo de correção do kernel importa. Nos planos elegíveis, KernelCare permite aplicar o patch compatível sem esperar a próxima janela de reboot; a equipe também confere o kernel instalado e o efetivamente iniciado. CloudLinux/CageFS e Imunify360 ajudam a conter o primeiro estágio, mas o patch do kernel é indispensável para fechar a elevação a root.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

• CloudLinux — status e kernels corrigidos para RefluXFS
• Qualys no oss-security — análise técnica da CVE-2026-64600
• CVE.org — CVE-2026-64600

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.