Zapscape CVE-2026-64561: escape KVM e root local em versões CloudLinux

A Zapscape (CVE-2026-64561) é uma use-after-free no KVM x86. Em condições específicas, root dentro de uma VM pode alcançar root no hypervisor; em shared hosting, um usuário capaz de abrir /dev/kvm pode criar um guest descartável e atacar o host. CloudLinux publicou mitigações, kernels e livepatches.

O que aconteceu

Ao liberar páginas do shadow MMU, o kernel podia continuar usando uma raiz já marcada como inválida/obsoleta e criar páginas-filhas que violavam as invariantes do KVM. O pesquisador publicou proof of concept upstream. CloudLinux não reproduziu o escape com o exploit sem adaptação em seus kernels, mas considera o código alcançável e recomenda correção.

A cadeia exige nested virtualization e CPU AMD ou Intel Ice Lake-SP ou posterior com EPT de quatro e cinco níveis. Em CL8/9/10, permissões amplas de /dev/kvm podem abrir a rota mesmo quando o servidor não vende VMs. CageFS restringe usuários caged, mas não todos os serviços e guests.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

As três condições devem coexistir: acesso ao KVM, nested virtualization e CPU em escopo. Uma delas ausente bloqueia a cadeia descrita, mas o patch continua preferível porque configurações e workloads mudam.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto. CloudLinux cita classificação Important/CVSS 7,0 da Red Hat. A consequência plausível cruza a fronteira de VM ou eleva um usuário do shared host a root, alcançando outros tenants e seus dados.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Verifique /dev/kvm, nested virtualization, CPU, kernel e KernelCare. Em Intel, ept_5level identifica a condição adicional.

ls -l /dev/kvm 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
grep -w ept_5level /proc/cpuinfo | head -1
uname -r
kcarectl --patch-info 2>/dev/null | grep CVE-2026-64561

Modo 0666 em /dev/kvm permite todos os usuários; Y/1 indica nested ativo. AMD entra sem o teste EPT; em Intel, ausência de ept_5level retira essa rota. Compare o kernel com a linha correta.

Como corrigir ou mitigar

Em host sem VMs, descarregue e bloqueie KVM temporariamente. Em hypervisor, desabilite nested virtualization somente após drenar guests, ou instale o kernel corrigido. Restrinja /dev/kvm a grupo autorizado como defesa adicional. KernelCare está no main feed para 7h/8/9/10 e Ubuntu 22.04; LTS usa kernel ELS.

dnf update 'kernel*'
kcarectl --update
kcarectl --patch-info | grep CVE-2026-64561

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Confirme kernel/livepatch, permissões de /dev/kvm e estado nested. Teste guests e serviços. Procure panics, novos módulos, processos de virtualização inesperados e mudanças de privilégio. Não remova bloqueio antes de confirmar o patch.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

A WebinHost cruza hardware, KVM, permissões e nested virtualization para priorizar somente hosts realmente expostos, sem deixar os demais desatualizados. KernelCare reduz a necessidade de reboot quando há patch; CageFS e Imunify360 acrescentam defesa contra a rota que começa em site comprometido.

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 — advisory Zapscape
• CVE.org — CVE-2026-64561

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.