Zapscape: la vulnerabilidad de KVM que podría escapar de la VM y tomar el control del host

Zapscape es la etiqueta que recibió una vulnerabilidad crítica detectada en el subsistema KVM del kernel Linux que gestiona la MMU “shadow” para la traducción de memoria en entornos de virtualización anidada. El fallo, rastreado como CVE-2026-64561, permite que un atacante que ya tenga privilegios de kernel dentro de una máquina virtual L1 (es decir, normalmente root en esa VM) escape del aislamiento de KVM y ejecute código con privilegios del host. Aunque el vector requiere un contexto de privilegios elevados dentro del L1 y condiciones concretas en la CPU, el potencial impacto en entornos que exponen la virtualización anidada a invitados no confiables es significativo: un invitado malicioso podría comprometer el host y, por extensión, otras VMs y cargas de trabajo sobre ese host.

Técnicamente, la vulnerabilidad es un problema de orden en la comprobación de raíces obsoletas (stale-root) dentro del bookkeeping de la shadow-MMU que puede producir un use-after-free. Durante el manejo de una page fault provocada por el invitado, KVM puede reclamar páginas de MMU e invalidar la raíz de shadow-MMU que todavía está siendo usada en el camino de manejo de la falta. Como la ruta no vuelve a comprobar esa raíz, KVM puede continuar creando páginas hijas bajo una raíz invalidada, lo que conduce finalmente a enlaces colgantes y escrituras posteriores a la liberación. El investigador Hyunwoo Kim publicó una demostración técnica y un proof-of-concept público que muestra cómo, a partir de este primitivo, es posible ejecutar una cadena completa de explotación capaz de crear un archivo en el host (p. ej. /Zapscape) con propiedad del root del host.

Hay condiciones concretas para que el ataque sea explotable: además del requisito habitual de privilegios de kernel dentro de L1, en sistemas Intel es necesario exponer al invitado L1 la longitud de page-walk de EPT tanto 4 como 5; AMD no exige esa condición adicional y el PoC público de Kim está dirigido a SVM/NPT en AMD sobre Linux 7.1.3. Es importante subrayar que QEMU no es el componente vulnerable: el fallo vive en el código in-kernel de KVM y puede desencadenarse independientemente del emulador; Kim incluso recomienda usar QEMU TCG para pruebas seguras del PoC porque QEMU en sí no es la superficie explotable.

El panorama de parches ya es claro: el arreglo upstream fue fusionado (commit 2abd5287f083) y mueve la comprobación de stale-root para después de make_mmu_pages_available(), haciendo que, si la reclamación invalida la raíz actual, KVM reinicie el fallo con RET_PF_RETRY en lugar de continuar en una raíz inválida. La NVD lista kernels desde 5.9 en adelante como afectados hasta las versiones estables parcheadas; entre las versiones con el arreglo upstream se mencionan 6.6.148, 6.12.101, 6.18.42 y 7.1.6. Los administradores deben revisar además los avisos de sus distribuciones porque muchos distribuidores (por ejemplo, Red Hat) aplican parches en forma de backports dentro de paquetes con numeraciones distintas a la de upstream. Puede consultarse el seguimiento oficial en la NVD y el commit en el repositorio del kernel: NVD — CVE-2026-64561 y commit 2abd5287f083 en git.kernel.org.

En cuanto a riesgo real y mitigación operativa: Kim aclara que el PoC no es “armamento listo para la nube” inmediato; un exploit en producción requeriría portar acciones L1 a un módulo de kernel en el invitado y adaptar la explotación a la configuración del kernel del host y a su backend de memoria. No obstante, la existencia de una prueba pública obliga a actuar con rapidez. Red Hat emitió una calificación preliminar CVSS 7.0 y clasificó el problema como CWE-825 (expired pointer dereference), lo que subraya la severidad y la posibilidad de escalada a control del host.

Si administras infraestructura basada en KVM y especialmente si expones nested virtualization o provees VMs “con capacidad de anidar” a clientes o usuarios, las acciones inmediatas recomendadas son: aplicar los parches oficiales o paquetes de tu distribuidor que incluyan la corrección, o si no es posible parchear de inmediato, deshabilitar la exposición de virtualización anidada a invitados no confiables. Además, audita qué invitados tienen privilegios de kernel (root) o acceso a hardware que permita activar condiciones de explotación, y minimiza el reparto de capacidades de virtualización en entornos multiinquilino. Comprueba los trackers de seguridad de tu distribución porque el estado y el número de versión pueden variar si el proveedor ha backporteado el fix.

Para equipos de respuesta e investigación interna que deseen reproducir o analizar el problema, el PoC público de Kim está disponible con su análisis técnico; usar QEMU TCG para pruebas reduce el riesgo de daños accidentales al no depender de aceleración por hardware. No uses pruebas del PoC en entornos de producción ni sobre hosts compartidos sin aislamiento estricto. Los enlaces del investigador y del aviso upstream permiten comprender la técnica y verificar el parche aplicado en el árbol oficial del kernel.

Zapscape es, en contexto, parte de una serie de descubrimientos recientes en KVM que incluyen fallos previos como Januscape (CVE-2026-53359) e ITScape (CVE-2026-46316), lo que evidencia que la complejidad del código de shadow-MMU y la virtualización anidada siguen siendo una superficie crítica. La lección operativa es priorizar parches de kernel en hosts de virtualización, reducir la exposición de características avanzadas a invitados no confiables y mantener políticas estrictas de privilegios dentro de las VMs. Para confirmaciones y guías de remediación específicas a tu distribución, consulta además las páginas de seguridad de tu proveedor y las notas de lanzamiento: por ejemplo, las páginas de Red Hat sobre CVE y los repositorios de kernel de tus distribuciones.

Fuentes y referencias para seguir la respuesta: el registro oficial del CVE en la NVD, el commit del kernel con el parche y las páginas de seguridad de distribuidores como Red Hat. Consulta estos recursos para verificar que tus hosts están en versiones parcheadas o que tus paquetes incluyen el backport correspondiente antes de considerar un entorno seguro frente a CVE-2026-64561.