Una nueva vulnerabilidad en KVM/x86, identificada como CVE-2026-64561 y conocida como Zapscape, vuelve a recordar la importancia de mantener actualizado el hipervisor en cualquier infraestructura basada en Linux. Aunque muchos administradores la están asociando rápidamente con Proxmox VE, el problema no reside en Proxmox, sino en el propio Kernel-based Virtual Machine (KVM), el hipervisor integrado en el kernel Linux utilizado por Proxmox, OpenStack, oVirt y numerosas plataformas cloud.
Las claves de Zapscape en 30 segundos
- La vulnerabilidad CVE-2026-64561 afecta al componente KVM/x86 del kernel Linux.
- Permite un posible escape desde una máquina virtual al host mediante un fallo en el Shadow MMU.
- Requiere privilegios elevados dentro del invitado y, en muchos escenarios, virtualización anidada.
- No es una vulnerabilidad de QEMU ni de Proxmox VE, sino del kernel Linux.
- Los administradores deberían planificar la actualización del kernel tan pronto como existan paquetes corregidos para su distribución.
En los últimos meses KVM está recibiendo una atención especial por parte de investigadores de seguridad. Tras Januscape (CVE-2026-53359) llega ahora Zapscape, otra vulnerabilidad distinta pero localizada en el mismo componente del Shadow MMU, una de las piezas más complejas del subsistema de virtualización de Linux.
Un fallo en el Shadow MMU de KVM
Según explica el investigador Hyunwoo Kim (@v4bel), Zapscape es una vulnerabilidad Use-After-Free (UAF) que aparece durante la recuperación de páginas del Shadow MMU.
Durante determinadas operaciones recursivas, KVM libera una página raíz (shadow root page) que todavía continúa referenciada por el sistema. Posteriormente sigue utilizando esa estructura de memoria ya invalidada, lo que permite corromper memoria del kernel del host.
El resultado potencial es especialmente serio: un invitado podría conseguir ejecutar código con privilegios de kernel en el servidor físico.
No afecta únicamente a Proxmox VE
Uno de los errores que ya se están viendo en numerosos titulares es presentar Zapscape como una vulnerabilidad exclusiva de Proxmox.
No lo es.
El problema afecta a cualquier infraestructura que utilice KVM/x86 vulnerable, independientemente de la plataforma de gestión utilizada.
Entre ellas pueden encontrarse:
- Proxmox VE.
- OpenStack.
- Plataformas cloud privadas basadas en libvirt.
- Hipervisores KVM personalizados.
- Grandes proveedores cloud que utilizan KVM como motor de virtualización.
Al tratarse de un fallo del kernel, actualizar únicamente Proxmox VE no elimina el riesgo si el kernel continúa siendo vulnerable.
¿Puede explotarse fácilmente?
La respuesta corta es no.
Aunque la vulnerabilidad permite un escenario de alto impacto, la explotación requiere varias condiciones.
Requisitos descritos por el investigador
| Condición | Necesaria |
|---|---|
| Host con KVM vulnerable | ✅ |
| Invitado con privilegios root | ✅ |
| Virtualización anidada disponible | Habitualmente sí |
| Arquitectura x86 | ✅ |
| Configuración específica del Shadow MMU | ✅ |
Esto significa que muchos entornos empresariales tradicionales presentan un riesgo inferior al de un proveedor cloud multiinquilino donde clientes externos ejecutan máquinas virtuales bajo su propio control.
El mayor riesgo está en los entornos cloud
En un escenario de nube pública el atacante normalmente dispone de privilegios de administrador dentro de su propia máquina virtual.
Si además el proveedor expone virtualización anidada, la vulnerabilidad podría utilizarse para intentar comprometer el host físico.
Según el documento publicado por el investigador, un ataque exitoso podría permitir:
- ejecutar código como root en el host;
- provocar una caída del kernel (DoS);
- comprometer otras máquinas virtuales alojadas en el mismo servidor físico.
Precisamente por ello este tipo de vulnerabilidades suelen tratarse con máxima prioridad por los grandes operadores cloud.
La prueba de concepto ya es pública
Tras finalizar el embargo coordinado con los mantenedores del kernel Linux, el autor ha publicado tanto la documentación técnica como una prueba de concepto (PoC).
No se trata de un exploit preparado para ejecutarse directamente contra proveedores cloud comerciales, sino de un entorno de demostración construido sobre QEMU TCG que reproduce toda la cadena de explotación.
No obstante, el propio investigador señala que adaptar el exploit a otros entornos no resulta especialmente complejo.
Versiones afectadas
La vulnerabilidad afecta al código introducido entre los commits:
- f95eec9bed76 (8 de julio de 2020)
- 2abd5287f083 (21 de julio de 2026)
Esto implica que numerosas versiones del kernel Linux pueden estar afectadas hasta la incorporación de los parches correspondientes.
Buenas prácticas para administradores de sistemas
Mientras las distribuciones Linux publican las actualizaciones definitivas, los administradores deberían revisar especialmente los servidores que ejecuten cargas de terceros.
Las recomendaciones más razonables incluyen:
- instalar cuanto antes los kernels corregidos cuando estén disponibles;
- limitar la virtualización anidada únicamente a los casos necesarios;
- restringir el acceso a /dev/kvm;
- revisar las notas de seguridad de la distribución utilizada;
- planificar una política de actualización periódica del hipervisor.
Zapscape también vuelve a poner de manifiesto que mantener actualizado únicamente Proxmox VE no siempre es suficiente. En muchas ocasiones las vulnerabilidades más críticas llegan a través del kernel Linux, por lo que disponer de un proceso ágil para actualizar los nodos de virtualización resulta tan importante como proteger las propias máquinas virtuales.
Preguntas frecuentes
¿Zapscape es una vulnerabilidad de Proxmox VE?
No. El fallo reside en KVM/x86, el hipervisor integrado en el kernel Linux utilizado por Proxmox VE y otras plataformas.
¿Está afectado QEMU?
No. Según el investigador, la vulnerabilidad se encuentra en KVM y puede reproducirse independientemente del software de emulación utilizado.
¿Es necesario tener permisos dentro de la máquina virtual?
Sí. La explotación descrita requiere privilegios elevados dentro del sistema invitado.
¿Qué deberían hacer los administradores?
Actualizar el kernel cuando existan parches disponibles, revisar si utilizan virtualización anidada y seguir las recomendaciones publicadas por su distribución Linux y por el proyecto Proxmox.
