Zapscape (CVE-2026-64561): cómo un invitado L1 con privilegios de kernel puede escapar de KVM al host

# Zapscape (CVE-2026-64561): cómo un invitado L1 con privilegios de kernel puede escapar de KVM al host

Cuando un guest con permisos de root dentro de una máquina virtual logra ejecutar código en el hipervisor que lo contiene, el modelo de seguridad de la virtualización se rompe por su base. La promesa que los proveedores de cloud y los administradores de数据中心 hacen a sus clientes — aislamiento entre tenants, separación entre cargas de trabajo, garantía de que una VM comprometida no afecta a las demás — depende de que esa frontera no se cruce. CVE-2026-64561, divulgado públicamente como Zapscape el 6 de agosto de 2026, describe exactamente ese cruce: un fallo de use-after-free en la emulación del shadow MMU de KVM/x86 que permite a un guest privilegiado escapar al host y ejecutar código con privilegios de kernel sobre el sistema host. La vulnerabilidad es obra del investigador Hyunwoo Kim, que venía publicando una serie de hallazgos similares en la pila de virtualización de Linux — Zapscape es el tercero de la trilogía después de ITScape (CVE-2026-46316, sobre KVM/arm64) y Januscape (CVE-2026-53359, también sobre el shadow MMU de KVM/x86).

Qué es el shadow MMU y por qué importa aquí

KVM, el hypervisor basado en el kernel de Linux, ofrece aceleración de hardware para la virtualización mediante extensiones de CPU como Intel VT-x y AMD-V. El MMU asistido por hardware (EPT en Intel, NPT en AMD) traduce direcciones de guest a direcciones de host directamente, sin que el hipervisor intervenga en cada traducción. Pero cuando un guest ejecuta otro hypervisor — es decir, cuando hay virtualización anidada, donde un guest L0 hospeda un guest L1 que a su vez podría hospedar un guest L2 — la traducción de direcciones se vuelve recursiva. KVM/x86 maneja esa recursión usando un componente software llamado shadow MMU, que mantiene las llamadas shadow page tables: tablas que traducen direcciones del guest L2 a direcciones del guest L1, que luego serán traducidas por el hardware al host.

El shadow MMU es una pieza compleja. Maneja páginas, raíces de tablas de páginas, cachés de traducciones y contabilidad de referencias. Cada vez que una página del shadow MMU ya no se necesita, el código la libera; cada vez que se vuelve a necesitar, se reclama. La función `mmu_page_zap_pte()`, que Zapscape pone en el centro de la vulnerabilidad, se encarga de borrar entradas en shadow page tables durante esa reclamación. El problema es que esa función no verifica adecuadamente un contador de referencias (`root_count`) que debería protegerla contra condiciones de carrera en las que la raíz de la tabla de páginas ha sido invalidada mientras la función sigue operando sobre ella.

Cómo funciona el exploit

El exploit aprovecha un orden incorrecto entre dos operaciones: la verificación de si una raíz de shadow MMU es stale, y la ejecución de una operación que puede invalidar esa raíz. En el código vulnerable, KVM comprueba primero si la raíz ha sido invalidada por la reclamación de páginas MMU, y luego procede a usar esa raíz para mapear o fetchar más páginas. Pero la reclamación puede ocurrir entre la verificación y el uso, invalidando la raíz después de que KVM ya decidió que era válida. KVM continúa entonces operando con una raíz inválida — un puntero que apunta a memoria que ya no le pertenece — y eso es textualmente un use-after-free.

En términos de impacto, un use-after-free sobre estructuras del kernel de Linux que controlan shadow page tables termina, después de varias iteraciones, dando al atacante control sobre qué código se ejecuta en el contexto del kernel del host. El investigador Hyunwoo Kim demostró una cadena de exploit que termina ejecutando comandos en el host con privilegios de root. El código PoC es público y está disponible en el repositorio del investigador.

Las condiciones previas: lo que un atacante necesita

Zapscape no es un fallo que cualquier guest pueda explotar. La condición previa principal es que el atacante ya tenga privilegios de kernel dentro del guest L1 — es decir, ya sea root dentro de la VM. Eso reduce la superficie de ataque inmediato a escenarios donde el atacante ya tiene cierto nivel de compromiso: una VM multi-tenant donde un cliente ha logrado escalar privilegios, un guest interno que el atacante controla por otras vías, o un entorno de virtualización anidada donde el L1 es accesible por el L2.

Sobre Intel, hay una condición adicional: tanto EPT page-walk length 4 como page-walk length 5 deben estar expuestos al L1. Esto es relevante porque la virtualización anidada en Intel normalmente limita las longitudes de page-walk disponibles para el L1, y solo cuando ambas longitudes están expuestas se cumple el requisito. Sobre AMD, esa condición no existe: la explotación es viable sin configuraciones específicas de page-walk.

El resultado es que Zapscape es especialmente grave en escenarios de virtualización anidada con guests no confiables. Los proveedores de cloud pública con soporte para virtualización anidada, los entornos de investigación donde se ejecutan hipervisores dentro de VMs, y las organizaciones que ejecutan cargas multi-tenant sobre KVM deberían tomar este CVE con la máxima seriedad.

La línea de tiempo de divulgación

La divulgación de Zapscape siguió un proceso razonablemente ordenado. Kim reportó el fallo a security@kernel.org el 11 de julio de 2026. Un parche fue desarrollado y mergeado en el kernel el 21 de julio, con el commit `2abd5287f083`. El 1 de agosto, el asunto se envió a la lista linux-distors bajo un embargo de cinco días. El CVE-2026-64561 fue asignado el 4 de agosto. La divulgación pública siguió el 6 de agosto.

El fix, según el commit, mueve la verificación de stale-root después de la llamada a `make_mmu_pages_available()`. Si la reclamación invalida la raíz actual, KVM ahora reinicia el fault con `RET_PF_RETRY` en lugar de continuar mapeando o fetchando con la raíz inválida. Es una corrección quirúrgica que ataca exactamente la condición de carrera sin tocar la lógica general del shadow MMU.

Mitigaciones inmediatas para quien no puede parchear hoy

Para organizaciones que ejecutan KVM hosts con virtualización anidada expuesta a guests no confiables, hay tres mitigaciones disponibles antes de poder aplicar el parche.

La primera es desactivar la virtualización anidada. En sistemas Intel, donde el ataque requiere nested EPT page-walk con ambas longitudes expuestas, eliminar la virtualización anidada cierra el vector primario. En sistemas AMD, donde la vulnerabilidad se puede activar también sin virtualización anidada, la desactivación reduce pero no elimina la exposición. La configuración específica varía según la distribución: en muchos kernels, `modprobe -r kvm-intel nested=0` o el equivalente en `/etc/modprobe.d/` surte efecto. Es una mitigación que tiene coste funcional — los usuarios legítimos que necesitan nested virt pierden la capacidad — pero en escenarios donde nested virt no es una feature de negocio, es la opción más limpia.

La segunda es actualizar el kernel. Los vendors principales de Linux ya han publicado kernels con el backport del fix. Para Red Hat Enterprise Linux y derivados como Rocky Linux, las versiones 8, 9 y 10 tienen actualizaciones; CIQ publicó una guía específica de mitigación para esas variantes. Para Ubuntu, los kernels HWE y GA actualizados incluyen el backport. Para Debian, los kernels en stable tienen el fix. Para quienes compilan su propio kernel, aplicar commit `2abd5287f083` o uno posterior cierra la vulnerabilidad.

La tercera es revisar quién tiene acceso a L1. Si tu entorno de virtualización no necesita virtualización anidada, desactívala por defecto y habilítala solo en tenants o cargas específicas donde sea estrictamente necesaria. Si la necesitas, segmenta: no permitas que guests L1 ejecuten cargas arbitrarias o sean controlados por usuarios externos sin un nivel adicional de revisión. La explotación requiere L1 root, así que cualquier medida que eleve el coste de obtener root dentro de L1 mitiga parcialmente el riesgo.

Detección y monitorización

Detectar un intento de explotación de Zapscape no es trivial. El exploit opera dentro del guest L1 y los síntomas aparecen en el host como comportamiento anómalo del kernel. Las señales a buscar incluyen crashes del kernel en código del shadow MMU — específicamente en funciones como `mmu_page_zap_pte()` o en manejadores de fault del MMU — que aparezcan poco después de que un guest L1 haya realizado operaciones intensivas de page table management. Un kernel panic con un stack trace apuntando a esas funciones, en un host que ejecuta virtualización anidada, es un candidato fuerte a investigación.

También vale la pena monitorizar logs de QEMU y libvirt por operaciones de KVM inesperadas. Si tu host ejecuta QEMU con monitor habilitado, revisar el monitor por llamadas anómalas a `dump-guest-memory` o por cambios en la configuración de page tables del guest puede dar pistas. Pero la detección más fiable sigue siendo la prevención: parchear, restringir nested virt, no exponer guests no confiables a L1.

La trilogía de Kim y qué sugiere sobre la superficie

Zapscape no es un caso aislado. Es el tercero de tres vulnerabilidades de escape de VM publicadas por Hyunwoo Kim en 2026: ITScape sobre KVM/arm64 en junio, Januscape sobre shadow MMU de KVM/x86 en julio, Zapscape sobre shadow MMU de KVM/x86 en agosto. Tres hallazgos en tres meses, todos contra la misma pila de virtualización, todos permitiendo escapar del guest al host. Eso no es mala suerte; es una superficie que admite más investigación.

Para los equipos de plataforma que ejecutan virtualización KVM en producción, la implicación es que deben asumir que habrá más CVEs de esta clase. La respuesta razonable es estructural: tratar la pila de virtualización como código crítico de seguridad, no como infraestructura commodity. Eso significa invertir en monitorización específica, en procesos de parcheo acelerado para kernels, en segmentación estricta entre tenants, y en un programa de threat modeling que considere explícitamente el caso "atacante con root dentro de guest". Si esos elementos están en su sitio, la próxima variante de Zapscape se enfrentará a una organización que responde en horas, no en semanas.

Cierre

Zapscape es un recordatorio de que la virtualización, aunque lleva décadas madurando, no es una capa de seguridad infalible. La combinación de un fallo de orden de operaciones en código complejo, una condición previa realista en entornos multi-tenant, y un PoC público disponible, lo convierte en una vulnerabilidad seria para cualquier organización que ejecute KVM con virtualización anidada expuesta. La acción inmediata es parchear; la acción estructural es revisar la segmentación y los accesos a L1. Y la conversación a mantener abierta es la que lleva haciéndose desde ITScape: la pila de virtualización de Linux merece el mismo nivel de inversión en seguridad que cualquier otra pieza de infraestructura crítica, porque las consecuencias de un fallo ahí son catastróficas para el modelo multi-tenant completo.

Por qué los proveedores de cloud deberían preocuparse especialmente

Los proveedores de cloud pública que ofrecen instancias con soporte para virtualización anidada son el escenario de peor caso para Zapscape. Una instancia cloud normal — sin nested virt — ejecuta directamente sobre el hardware del proveedor, con KVM como L0 y el sistema operativo del cliente como L1. Eso ya es vulnerable a cualquier escape L1→L0 si existiera; pero el modelo de negocio del proveedor depende de que no exista. Zapscape requiere que el L1 ya esté corriendo un hypervisor que a su vez maneje un L2; es decir, requiere nested virt activada y un L2 controlado por el atacante. Eso es un escenario raro pero no imposible, especialmente en proveedores que ofrecen "bare metal as a service" donde el cliente controla el L1 por completo, o en proveedores que han decidido activar nested virt por defecto para soportar casos de uso legítimos.

Para un proveedor de cloud, la mitigación correcta no es solo parchear — eso se hace por defecto — sino reconsiderar cuándo y cómo se ofrece virtualización anidada. Activarla por defecto para todos los tenants expande innecesariamente la superficie de ataque. Activarla solo bajo petición explícita, con revisión de la justificación y con monitorización reforzada sobre esos tenants específicos, reduce la superficie sin perder capacidad funcional. Esa decisión es de producto y de plataforma, no solo de seguridad.

Lo que un atacante con root en L1 realmente puede hacer después

Una vez que la explotación de Zapscape tiene éxito y el atacante ejecuta código en el host con privilegios de kernel, las opciones son las mismas que tendría un atacante que lograra root en el host directamente. Puede leer memoria de cualquier otra VM en el mismo host. Puede modificar el comportamiento del hypervisor para interceptar operaciones de otros guests. Puede plantar persistencia en el host — módulos de kernel maliciosos, reglas de iptables modificadas, servicios systemd alterados — que sobrevivan al reinicio del host o incluso a la reinstalación de guests individuales. Puede pivotar hacia la red de gestión del proveedor, que es donde residen las herramientas de provisionamiento y monitorización. En resumen: un escape L1→L0 exitoso es equivalente a comprometer el host físico, con todo lo que eso implica en términos de acceso a otros tenants, a la infraestructura de gestión, y a los secretos que residen en ese host.

Por eso la respuesta correcta a Zapscape no es solo parchear; es revisar la arquitectura de seguridad de la capa de virtualización como un todo. La pregunta útil que un equipo de seguridad puede hacerse es: si un atacante lograra root en uno de nuestros hosts KVM hoy, ¿qué datos y sistemas quedarían accesibles? La respuesta a esa pregunta revela las consecuencias potenciales de Zapscape y de cualquier futura variante de la misma clase.