A sua máquina virtual já não é uma fronteira: o que o Zapscape revela sobre o KVM

Uma nova vulnerabilidade no hipervisor KVM do Linux voltou a colocar em causa aquilo que muitas organizações tratam como um dado adquirido: a separação entre uma máquina virtual e o servidor físico que a aloja. Batizada Zapscape e registada como CVE-2026-64561, a falha foi divulgada publicamente a 6 de agosto de 2026 pelo investigador Hyunwoo Kim e permite, em condições específicas, que código a correr dentro de um convidado (guest) escape para o anfitrião (host) e execute comandos com privilégios de root. Existe já código de prova de conceito público, o que transforma a aplicação de atualizações do kernel numa prioridade operacional para quem opera virtualização em ambientes multi-inquilino.

O que é, afinal, o Zapscape

O problema vive no coração da tradução de memória virtualizada. De acordo com a documentação publicada pelo investigador, o Zapscape é uma falha de use-after-free na emulação da shadow MMU do KVM/x86, no caminho recursivo de “zap” que corre quando páginas-sombra são recuperadas; com ações executadas apenas do lado do convidado, um atacante pode comprometer o anfitrião que corre a sua máquina virtual — por exemplo, quem alugou uma única instância numa nuvem pública pode provocar um kernel panic que derruba todas as outras VM do mesmo servidor físico, ou executar código com privilégios de root no anfitrião.

Na prática, a origem do defeito é uma questão de ordem das verificações. A correção upstream resolve precisamente o problema de ordenação da validação da raiz obsoleta: em vez de validar a raiz do page fault antes de recuperar páginas da MMU, o código corrigido disponibiliza primeiro as páginas e só depois verifica se a raiz atual se tornou obsoleta, reiniciando o page fault em vez de construir estruturas-filhas por baixo de uma raiz inválida. A Red Hat descreve a falha como uma validação indevida das raízes de páginas da MMU depois de estas serem disponibilizadas, com o KVM a tentar mapear memória numa raiz inválida.

Ficha técnica da vulnerabilidade

A Red Hat classificou o problema como Important, com pontuação base CVSS 3.1 de 7.0 sob CWE-825, e publicou o vetor CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, sublinhando que se trata de métricas preliminares sujeitas a revisão. À data da divulgação, a NVD ainda não tinha publicado pontuação própria para o CVE-2026-64561. O tracker de segurança do Debian associa a correção ao commit 2abd5287f08319fa35764566b15c6e22cb1068db, integrado na 7.2-rc5.

Quem está realmente exposto

Nem todos os servidores com KVM correm o mesmo risco. As condições de exploração documentadas são exigentes e é isso que explica a distância entre uma pontuação CVSS de 7.0 e um impacto teórico devastador.

• Virtualização aninhada exposta. O cenário de risco é o de anfitriões KVM/x86 que aceitam convidados não confiáveis e expõem virtualização aninhada, em particular nuvens públicas x86 multi-inquilino.
• Privilégio de kernel no convidado L1. A fuga demonstrada exige privilégio de kernel em L1 — normalmente root no convidado —, um requisito que não elimina o risco porque é precisamente o que o inquilino tem na VM que administra.
• Diferença entre Intel e AMD. Ao contrário do Januscape, em Intel o problema só pode ser acionado quando os comprimentos de percurso de página EPT de nível 4 e 5 estão ambos expostos a L1; em anfitriões AMD com SVM e páginas aninhadas, a divulgação não identifica pré-requisito adicional de funcionalidade de CPU.
• Escalada local de privilégios. Em distribuições como o RHEL, onde /dev/kvm tem permissões 0666, um utilizador local sem privilégios pode usar a mesma falha como LPE para obter root — e, nesse caso, com ioctls do lado do VMM disponíveis, o exploit torna-se mais fácil e estável.

Convém ainda separar responsabilidades técnicas: a vulnerabilidade está na shadow MMU x86 do KVM dentro do kernel, e não na emulação de dispositivos do QEMU, ainda que o QEMU seja usado na demonstração laboratorial pública.

Cronologia e estado da correção

O próprio investigador indica que, após o reporte a [email protected] e o fim do embargo acordado, o exploit foi publicado na oss-security juntamente com a documentação do Zapscape. Foram identificadas versões estáveis corrigidas nas séries 6.1, 6.6 e 6.18 do kernel, mas a regra prática para quem usa distribuições é outra: o estado do pacote no tracker do fornecedor deve prevalecer sobre a simples comparação de números de versão upstream, até porque a Red Hat, por exemplo, não faz normalmente rebase para versões novas, aplicando antes backports, o que leva alguns scanners a reportar falsos positivos.

Indicadores, deteção e mitigação

Não existem, nesta fase, indicadores de comprometimento no sentido clássico (domínios, hashes ou endereços IP), porque se trata de exploração local contra o kernel e não de uma campanha de malware. Há, ainda assim, um artefacto útil para exercícios autorizados de validação: a prova de conceito publicada leva o kernel do anfitrião visado a criar o ficheiro /Zapscape, propriedade de root. A demonstração tem como alvo virtualização aninhada AMD SVM/NPT no Linux 7.1.3 e o investigador recomenda que os testes sejam feitos sob QEMU TCG.

• Instalar sem demora um kernel do fornecedor que contenha a correção upstream e reiniciar os anfitriões KVM afetados.
• Enquanto o patching não estiver concluído, desativar a virtualização aninhada para convidados não confiáveis sempre que operacionalmente viável.
• Restringir o acesso a /dev/kvm, rever as configurações dos anfitriões, identificar sistemas multi-inquilino expostos e acompanhar os avisos dos fornecedores.
• Confirmar que o kernel vulnerável deixou efetivamente de estar em execução: instalar o pacote não basta.

Estas recomendações seguem a linha do que tem sido divulgado por analistas de segurança: instalar prontamente o kernel corrigido e reiniciar, desativar a virtualização aninhada para convidados não confiáveis, limitar o acesso a /dev/kvm, rever configurações e monitorizar avisos — porque uma única fuga de convidado pode anular o isolamento de todo um servidor. Instalar o pacote do kernel não é suficiente se o kernel vulnerável se mantiver ativo. Quanto ao risco real: até 7 de agosto de 2026 não havia evidência pública de exploração ativa, e a própria divulgação não reivindica exploração em ambiente real.

Um padrão que se repete no KVM

O Zapscape não surge isolado. Segue-se a outra fuga de KVM divulgada pelo mesmo investigador, o Januscape (CVE-2026-53359), e as duas não devem ser tratadas como sinónimos: afetam a mesma área alargada da shadow MMU, mas têm causas-raiz diferentes. O Januscape existia no código partilhado por implementações Intel e AMD desde um commit integrado em agosto de 2010 e permitia a uma VM com root e virtualização aninhada corromper a contabilidade de páginas-sombra do anfitrião. O mesmo investigador está ainda associado ao ITScape (CVE-2026-46316), a falha equivalente em KVM/arm64. Em conjunto, os três casos sugerem que a superfície de ataque da emulação de paginação por software do KVM merece revisão estrutural, e não apenas correções pontuais.

Porque é que isto importa em Portugal

Grande parte da infraestrutura de alojamento nacional — fornecedores de cloud, casas de hosting, plataformas de VPS, laboratórios de desenvolvimento e ambientes de CI/CD — assenta em KVM. Para uma PME que aluga máquinas virtuais, esta notícia significa sobretudo uma pergunta a fazer ao fornecedor: qual o estado do patching do kernel dos anfitriões e se há virtualização aninhada exposta a inquilinos. Para quem opera os anfitriões, o cálculo é diferente: com prova de conceito pública, a janela entre divulgação e adaptação por atores maliciosos tende a estreitar-se.

No plano regulatório, uma fuga de hipervisor toca diretamente nos deveres de gestão de vulnerabilidades e de segurança da cadeia de fornecimento previstos no Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), aplicável a operadores de serviços digitais e de infraestruturas relevantes. Um incidente que resulte em acesso não autorizado a dados de vários clientes alojados no mesmo servidor pode ainda configurar violação de dados pessoais nos termos do RGPD, com obrigação de notificação à CNPD e, se aplicável, aos titulares. O CNCS e o CERT.PT são os pontos de contacto nacionais para reporte e coordenação de incidentes, e é boa prática incluir os anfitriões de virtualização — muitas vezes esquecidos nos ciclos de atualização por exigirem reinícios — no inventário formal de ativos críticos sujeitos a gestão de vulnerabilidades.

Perguntas frequentes

O Zapscape afeta todos os servidores Linux?

Não. A falha só é relevante em anfitriões x86 que usam KVM e, para o caminho de fuga documentado, que expõem virtualização aninhada a convidados não confiáveis. Servidores Linux sem virtualização KVM ativa não estão no cenário de ataque descrito, embora devam continuar a receber atualizações regulares do kernel.

Já existe exploração ativa desta vulnerabilidade?

Não há evidência pública de exploração em ambiente real conhecida à data desta publicação. Existe, no entanto, código de prova de conceito publicado, o que costuma acelerar tentativas de adaptação e justifica tratar a atualização como urgente.

Basta desativar a virtualização aninhada?

É uma mitigação temporária útil, mas não substitui a correção. Existe também um caminho de escalada local de privilégios em sistemas onde o dispositivo /dev/kvm é acessível a utilizadores sem privilégios, pelo que a atualização do kernel continua a ser a medida decisiva.

Como confirmo se o meu sistema já está corrigido?

Compare o pacote de kernel instalado com o tracker de segurança da sua distribuição, em vez de comparar apenas números de versão upstream, porque muitos fornecedores aplicam backports. Depois de instalar, confirme que o sistema reiniciou e que o kernel vulnerável já não está em execução.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelo investigador Hyunwoo Kim, pela Red Hat, pelo projeto Linux, pelo Debian Security Tracker e por analistas de segurança independentes.