Un fallo en KVM rompe el aislamiento en virtualización anidada
Un fallo en KVM rompe el aislamiento en virtualización anidada y abre la puerta a ejecutar código como root en Linux
El hypervisor KVM, pieza central de la pila de virtualización de Linux y de plataformas como Proxmox VE, RHEL o las grandes nubes públicas basadas en x86, vuelve a estar en el punto de mira tras la divulgación pública de Zapscape, una vulnerabilidad de tipo use-after-free registrada como CVE-2026-64561. El fallo reside en el componente de gestión de memoria conocido como shadow MMU y permite que un invitado con privilegios escape del aislamiento de la máquina virtual y ejecute código en el host con permisos de root. La divulgación se produjo el 6 de agosto de 2026, una vez levantado el embargo coordinado con los mantenedores del kernel, según la cobertura original publicada por Hispasec en su boletín Una al día y ampliada por The Hacker News, CloudLinux, TuxCare, Red Hat y la lista de correo oss-security de Openwall.
Zapscape fue descubierto por el investigador Hyunwoo Kim, conocido en la comunidad bajo el seudónimo V4bel, y notificado al equipo de seguridad del kernel Linux el 11 de julio de 2026. Tras un período de coordinación que incluyó la asignación formal del CVE el 4 de agosto y la notificación a la lista linux-distros el 1 de agosto, el código de prueba de concepto, el repositorio público con la investigación y un write-up técnico detallado vieron la luz el 6 de agosto. La fecha de expiración del embargo figura en el aviso distribuido por oss-security, mientras que medios como TuxCare y CloudLinux sitúan la divulgación coordinada el 7 de agosto por las diferencias de zona horaria, una discrepancia menor que no afecta a la cronología técnica del fallo.
La raíz del problema es un error de ordenación en dos rutas de manejo de page faults dentro del shadow MMU de KVM/x86. Cuando el hypervisor reclama páginas de sombra, existe un camino recursivo de "zap" que invalida la raíz de la tabla de páginas del invitado si se cumplen ciertas condiciones. El código vulnerable, introducido en el kernel Linux 5.9 mediante el commit f95eec9bed76 del 8 de julio de 2020, valida la raíz de sombra antes de reclamar las páginas en lugar de hacerlo después. Esto significa que, si la reclamación invalida la raíz activa, KVM continúa construyendo mappings bajo una raíz que ya ha sido marcada como inválida, generando referencias colgantes y condiciones de escritura posteriores a la liberación de memoria. El resultado es una use-after-free clásica que rompe la invariante del hypervisor: nunca deben existir mappings activos bajo una raíz obsoleta.
El fix upstream, autoría de Sean Christopherson y Paolo Bonzini, dos de los mantenedores históricos de KVM, se materializó en el commit 2abd5287f083, fusionado el 21 de julio de 2026. El parche reordena la comprobación de obsolescencia para que se ejecute después de make_mmu_pages_available(), modificando apenas una docena de líneas entre los ficheros arch/x86/kvm/mmu/mmu.c y arch/x86/kvm/mmu/paging_tmpl.h, pero cierra por completo la ventana de uso tras liberación. Distribuciones como AlmaLinux, Debian, Ubuntu y Oracle ya han publicado backports, mientras que las ramas estables del kernel incluyen las versiones 6.6.148, 6.12.101, 6.18.42, 7.1.6 y 7.2-rc5, según el calendario oficial de mantenimiento del kernel Linux.
La explotación práctica requiere la convergencia de tres condiciones, algo que reduce la superficie de ataque pero no la elimina. En primer lugar, la virtualización anidada debe estar habilitada en el host, una configuración cada vez más común en proveedores de infraestructura como servicio que ofrecen a sus clientes la posibilidad de correr hypervisores dentro de sus máquinas virtuales. En segundo lugar, el atacante necesita privilegios de root dentro de la máquina virtual L1, ya que el código que manipula el shadow MMU se ejecuta en el contexto del kernel del invitado. En tercer lugar, el procesador del host debe pertenecer a la familia AMD SVM con NPT, o bien a un Intel Ice Lake-SP o posterior, en cuyo caso se requiere además que el invitado L1 tenga acceso a longitudes de page walk EPT de cuatro y cinco niveles. En hardware AMD, la condición de Intel sobre las longitudes EPT no aplica, lo que amplía el abanico de sistemas vulnerables en ese frente.
Cuando estas tres condiciones se cumplen, el escenario más grave es el escape de máquina virtual. Un inquilino malicioso con root dentro de su invitado L1 crea un segundo nivel L2 y, mediante una secuencia de fallos de página cuidadosamente construida, consigue que el shadow MMU del host escriba en memoria liberada del kernel. El control salta entonces a código controlado por el atacante, que se ejecuta con los privilegios del anillo 0 del host y, por tanto, con capacidad para leer, escribir o terminar cualquier otra máquina virtual alojada en el mismo hardware, además de moverse lateralmente a través de la red de gestión. Este es el caso que ha documentado Kim en su prueba de concepto, donde un proceso no privilegiado dentro del invitado consigue crear un fichero llamado /Zapscape en el sistema de ficheros del host, propiedad de root, como demostración inequívoca de la ejecución remota de código fuera del aislamiento previsto.
Existe además un segundo vector que no requiere virtualización anidada y que preocupa especialmente a los proveedores de hosting compartido. En distribuciones como CloudLinux 8, 8 LTS, 9, 9 LTS y 10, el dispositivo /dev/kvm es world-writable, lo que significa que un usuario sin privilegios, o un sitio web comprometido, puede crear una máquina virtual desechable, habilitar virtualización anidada en su interior y atacar el kernel del host desde dentro, escalando hasta root sin necesidad de que el proveedor exponga conscientemente la virtualización anidada. CloudLinux ha confirmado este escenario en su advisory y, según recoge TuxCare, el PoC público no ha logrado completar un escape de host sobre kernels de CloudLinux en sus pruebas, limitándose por ahora a tirar el invitado L1, pero advierte que eso no significa que el vector sea teórico: solo indica que el código de demostración aún no ha sido adaptado a las peculiaridades de configuración y mitigaciones de esa distribución.
En cuanto a la severidad, Red Hat ha clasificado Zapscape como Importante con una puntuación CVSS 3.1 de 7.0, utilizando el vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, que refleja un ataque local de alta complejidad y privilegios bajos. La organización MITRE, por su parte, asigna una puntuación más alta, 8.8, con el vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, donde la diferencia principal estriba en la consideración del alcance: el impacto se extiende a otros componentes del sistema al escaparse del invitado original. Ambas puntuaciones comparten el mismo núcleo técnico, descrito como CWE-825, es decir, una desreferencia de puntero expirado. La discrepancia entre las dos métricas ilustra una tensión conocida en la industria: la severidad depende en gran medida del modelo de despliegue y de si el proveedor expone o no virtualización anidada a usuarios no confiables.
A la espera de actualizaciones, la comunidad coincide en una jerarquía de mitigaciones temporales. La más rápida, aunque drástica, consiste en descargar los módulos kvm_intel y kvm_amd mediante modprobe -r, lo que elimina la capacidad del sistema de ejecutar máquinas virtuales hasta el siguiente reinicio, y blacklistearlos en /etc/modprobe.d/ para que no vuelvan a cargarse automáticamente. Para entornos que necesitan seguir virtualizando, pero no exponen virtualización anidada, se puede limitar la exposición con echo 'options kvm_intel nested=0' o el equivalente en kvm_amd, decisiones que en Proxmox VE requieren drenar o detener los invitados y un reinicio del host. Adicionalmente, restringir los permisos de /dev/kvm al grupo de administradores mediante udev o reglas similares cierra el vector de hosting compartido y resulta una buena práctica incluso después de aplicar el parche. En todos los casos, el destino final es la actualización del kernel a una versión que contenga el commit 2abd5287f083 o un backport equivalente, y el reinicio del host.
El calendario de actualizaciones ya está en marcha. Red Hat ha publicado el aviso RHSA-2026:22147 y mantiene el Bugzilla 2510891 para coordinar la entrega de parches, mientras que distribuciones derivadas como AlmaLinux ya disponen del backport 048f1efd0c, fechado el 6 de agosto. Las distribuciones LTS que mantienen kernels más antiguos, como CloudLinux 7h y 8 LTS, están en fase beta o en preparación, según el panel de TuxCare, mientras que las ramas 9 y 10 ya reciben parches a través del flujo principal. KernelCare, el sistema de livepatch de la propia TuxCare, ofrece cobertura sin reinicio para 9 y 10 en su feed principal y prepara 7h, 8, 8 LTS, 9 LTS y Ubuntu 22.04 en su rama extendida. Para Ubuntu, la página oficial de CVE-2026-64561 documenta el estado por pocket y arquitectura, y Debian incluye la corrección en su ciclo estable de la rama 13.
El caso de Zapscape se inscribe en una serie más amplia de vulnerabilidades de escape de máquina virtual descubiertas en KVM a lo largo de 2026, todas ellas atribuidas al mismo investigador. Apenas dos meses antes, el 6 de julio, se divulgó Januscape, registrada como CVE-2026-53359, una use-after-free de dieciséis años de antigüedad que afectaba a kvm_mmu_get_child_sp() y que había sido explotada como zero-day en la competencia kvmCTF de Google, según documentaron The Hacker News y la Cloud Security Alliance. La primera de la serie, ITScape (CVE-2026-46316), afectaba a la emulación del vGIC-ITS en arquitecturas arm64 y se divulgó en junio, poniendo de manifiesto que la superficie de ataque del hypervisor se extiende más allá de x86. La coincidencia en la autoría y el corto espacio entre divulgaciones sugiere que Kim ha centrado su investigación de manera sistemática en el shadow MMU y las rutas de traducción de direcciones, un área del kernel que, por su complejidad y por la necesidad de mantener invariantes muy estrictas bajo condiciones de concurrencia, sigue siendo fértil para hallazgos de este calibre.
La pregunta operativa para administradores de plataformas basadas en KVM es clara: aunque ningún proveedor importante haya confirmado explotación activa de CVE-2026-64561 en entornos reales, la existencia de un PoC público, la disponibilidad de los parches y la severidad cualitativa del escape hacen de esta vulnerabilidad un parche prioritario. Proxmox VE, presente en buena parte de los homelabs y pequeños proveedores, recibe su backport a través del kernel de la distribución sobre la que corre, normalmente Debian, Ubuntu o Enterprise Linux, por lo que la vía de actualización es la del sistema operativo y no la de un repositorio propio del hypervisor. Los grandes proveedores de nube, por su parte, deben evaluar si la virtualización anidada forma parte de su oferta a clientes externos y, en caso afirmativo, planificar la implementación del parche de manera escalonada para evitar indisponibilidad, posiblemente apoyándose en livepatching donde esté disponible y restringiendo el acceso anidado a los tenants que realmente lo necesiten mientras tanto.
Para los equipos de seguridad que monitorizan su superficie de ataque, conviene recordar que el shadow MMU de KVM no es la primera línea de defensa, sino el último recurso cuando un invitado ya comprometido intenta cruzar la frontera de aislamiento. Las buenas prácticas, vigentes desde hace años pero que Zapscape vuelve a poner de actualidad, pasan por mantener inventariados los nodos que tienen /dev/kvm expuesto, aplicar el principio de menor privilegio en los grupos que pueden acceder a él y auditar periódicamente los kernels en producción para detectar versiones vulnerables. Herramientas como Lynis, OpenSCAP o los propios scripts de mantenimiento de cada distribución pueden automatizar parte de esta auditoría, pero ningún sustituye a una política disciplinada de gestión de parches y de configuración de hypervisor. En este sentido, Zapscape actúa como recordatorio de que la complejidad del shadow paging en KVM sigue generando oportunidades para investigación ofensiva de alto impacto, y que los equipos azules deben planificar su respuesta con el mismo rigor con el que los rojos planifican la búsqueda de nuevas rutas de escape.
Finalmente, el aspecto humano del hallazgo merece una mención. Hyunwoo Kim, conocido como V4bel, ha pasado de ser un nombre poco conocido a figurar como descubridor único de tres vulnerabilidades de escape de máquina virtual en KVM en menos de tres meses, dos de ellas en x86 y una en arm64. Cada una de estas divulgaciones ha venido acompañada de un write-up técnico cuidado, un repositorio reproducible y un PoC funcional, lo que convierte a Kim en uno de los investigadores más prolíficos en el área de seguridad de hypervisores del momento. La comunidad KVM, por su parte, ha mantenido un ritmo de respuesta notable: el parche de Zapscape estuvo listo y revisado apenas diez días después de la notificación inicial, y los backports para distribuciones se sucedieron en cuestión de días una vez levantado el embargo. Es un recordatorio de que la salud del ecosistema open source se mide también por la calidad de su respuesta a incidentes, no solo por la calidad del código.