Informações divulgadas recentemente revelam uma vulnerabilidade que coloca servidores em nuvem em risco. Essa vulnerabilidade permite que invasores assumam o controle total da máquina física , um cenário catastrófico para provedores de infraestrutura em nuvem.
O Zapscape, registrado sob o identificador CVE-2026-64561, é uma vulnerabilidade crítica no hipervisor KVM do Linux que expõe um risco que muitas plataformas assumem inadvertidamente ao habilitar a virtualização aninhada. Essa vulnerabilidade permite que um atacante com privilégios de kernel em uma máquina virtual (L1) execute código com privilégios de root no sistema host (L0), quebrando o isolamento de ambientes virtualizados.
Considerado uma ameaça de alto impacto, o Zapscape não apenas facilita a fuga da máquina virtual, mas também abre uma rota de escalonamento de privilégios local para usuários do host que possuem permissões de escrita no dispositivo /dev/kvm.
Embora organizações como a Red Hat tenham classificado a vulnerabilidade com uma pontuação CVSS de 7.0, focando em instabilidade e negação de serviço, a prova de conceito (PoC) pública demonstra um alcance muito mais destrutivo: a criação de um arquivo arbitrário diretamente na raiz do host.
Caos na unidade de gerenciamento de memória
O funcionamento do Zapscape está oculto na Unidade de Gerenciamento de Memória (MMU) do KVM e na forma como o hipervisor lida com as tabelas de páginas quando um convidado (L1) atua como hipervisor para outro subconvidado (L2). O problema reside em um erro de ordem lógica durante o tratamento de falhas de página. Nos caminhos de código do kernel, a verificação de uma "raiz obsoleta" era executada antes da função de recuperação de página, em vez de depois.
Essa sequência incorreta desencadeia um cenário clássico de uso após liberação (use-after-free) . Durante a recuperação, o KVM pode remover o diretório raiz que está usando e marcá-lo como inválido. No entanto, como a verificação de integridade já foi executada, o sistema continua a criar mapeamentos sob um diretório raiz que não é mais válido. Curiosamente, esse problema de ordenação existe no código desde 2008, mas tornou-se crítico e explorável após o lançamento do kernel Linux 5.9 em julho de 2020 , quando uma diretiva foi introduzida e o sistema simplesmente parou de aplicá-la.
Requisitos e limitações
Para que o Zapscape seja explorável, o ambiente deve atender a requisitos muito específicos. Primeiro, a virtualização aninhada deve estar habilitada no módulo KVM, uma configuração que permite uma arquitetura de três camadas (L0, L1 e L2). O atacante precisa iniciar o ataque a partir da camada L1 , o que requer privilégios de root nessa máquina virtual. A partir daí, o atacante manipula os modos de memória enquanto a atividade da submáquina virtual L2 força o host L0 a iniciar a recuperação de páginas de cota, causando corrupção de memória.
Em termos de hardware, as condições variam dependendo do fabricante. Em sistemas AMD que utilizam tabelas de páginas aninhadas ( SVM ), a vulnerabilidade é mais simples e não requer recursos adicionais. Por outro lado, em processadores Intel, o cenário exige que o sistema convidado de camada 1 tenha exposto recursos de navegação de páginas EPT de quatro e cinco níveis . Isso limita o vetor de ataque em processadores Intel a arquiteturas mais recentes, especificamente da família Ice Lake-SP em diante.
Vale ressaltar que, embora a prova de conceito pública tenha conseguido escapar para o host em ambientes controlados, pesquisadores de segurança relataram que, em certos kernels recompilados, o exploit simplesmente trava a máquina virtual do atacante, funcionando como uma negação de serviço em vez de uma fuga completa.
Mitigação, correções e estratégias
A solução definitiva para o Zapscape chegou aos repositórios do Linux em julho passado com um patch que corrige a ordem de validação. Essa correção realoca a verificação de raiz obsoleta para ocorrer após a alocação de páginas da MMU, garantindo que o hipervisor não crie mapeamentos ativos sob uma raiz excluída. Essas correções já foram implementadas nas versões estáveis do kernel e estão sendo amplamente distribuídas por diversas distribuições.
Para administradores que não podem atualizar imediatamente, existem soluções temporárias altamente eficazes. A ação prioritária é desativar a virtualização aninhada em todos os servidores onde ela não é estritamente necessária, passando o parâmetro `nested=0` para os módulos `kvm_amd` ou `kvm_intel` nos arquivos de configuração do modprobe. Essa medida requer a reinicialização do módulo, o que significa interromper todas as máquinas virtuais ativas.
Por fim, se tiver interesse em saber mais, você pode encontrar os detalhes no seguinte link.