El 6 de agosto se publicó Zapscape, una vulnerabilidad en KVM (CVE-2026-64561) que permite a un atacante saltar del guest al host y ejecutar código con privilegios de kernel. Yo llevo años montando tiendas y webs en VPS compartidos, y la primera reacción del sector siempre es la misma: «pero eso requiere acceso root dentro de la máquina virtual». Cierto. Hasta que dejas de pensar en tu propio servidor y empiezas a mirar el VPS de 4 euros que comparte hipervisor con decenas de clientes más.
Hyunwoo Kim (@v4bel) presentó Zapscape como la tercera pieza de una trilogía de escapes en KVM, después de ITScape y Januscape. La diferencia no está tanto en la gravedad — un guest-to-host con ejecución como root en el host ya es lo máximo que puedes pedir en una CVE — sino en lo que demuestra sobre la promesa de aislamiento del cloud barato. Según el repositorio público del investigador, el fallo es un use-after-free en la emulación shadow MMU de KVM/x86. Un guest con privilegios de kernel y virtualización anidada activada puede corromper páginas shadow del host y, en la cadena demostrada, crear un archivo en el sistema host con uid 0.
En AMD, el PoC funciona con SVM/NPT anidado sin condiciones extra raras. En Intel la cosa se complica: hace falta que tanto EPT de 4 como de 5 niveles estén expuestos al guest L1, lo que limita el vector a hosts Ice Lake-SP y posteriores. Pero «limita» no es «imposible». Si tu proveedor ofrece nested virtualization en su panel — algo que muchos VPS baratos venden como feature para desarrolladores — la superficie existe.
Lo que tu hosting te dirá (y lo que no)
La respuesta corporativa ya la conozco: «usamos parches actualizados», «monitorizamos el kernel», «nuestros clientes no tienen nested virtualization habilitado por defecto». Todo puede ser verdad y aun así no responderte lo que importa: ¿en qué versión exacta del kernel corre el hipervisor que aloja tu VPS? Porque el parche upstream llegó el 21 de julio (commit 2abd5287f083) y la divulgación pública fue el 6 de agosto. Eso deja quince días de ventana en los que un proveedor distraído — o uno que prioriza márgenes sobre parches — puede tener máquinas expuestas.
Penligent recoge que las ramas estables corregidas incluyen 6.6.148, 6.12.101, 6.18.42, 7.1.6 y 7.2-rc5, con CVSS preliminar de Red Hat en 7.0. No hay, que yo sepa, explotación masiva confirmada en producción. Pero tampoco hace falta: el PoC está en GitHub y la cadena completa en AMD ya está documentada. En un entorno multi-tenant donde no controlas quién alquila la VM de al lado, «aún no lo han usado en la calle» me suena a consuelo barato.
Lo que más me irrita es el desfase entre marketing y realidad. Leaseweb subió ayer sus VPS de entrada casi al doble citando la escasez de RAM; Hostinger compra 3.000 servidores para absorber costes. Todos hablan de capacidad y precio. Nadie manda un email diciendo «hemos parcheado el kernel del hipervisor contra Zapscape». Si te llega un aviso genérico de «mantenimiento programado», ¿sabes distinguir un reboot rutinario de un parche de seguridad crítico? Yo no lo haría sin preguntar directamente al soporte.
¿Deberías migrar, apagar nested virt o simplemente ignorarlo?
Si tienes un VPS dedicado solo para ti, con acceso restringido y sin nested virtualization, el riesgo baja mucho. El atacante necesita root dentro del guest y la feature activada. Pero piensa en escenarios reales: equipos de desarrollo que levantan VMs dentro del VPS para probar Kubernetes, labs de formación, agencias que dan sandbox a clientes. Ahí nested virt no es un capricho, es el día a día. Y ahí Zapscape deja de ser teórico.
Mis recomendaciones, sin dramatismo pero sin ingenuidad:
- Pregunta a tu proveedor la versión del kernel del host y la fecha del último parche de seguridad KVM. Si no te la dan, eso ya es una respuesta.
- Si no necesitas nested virtualization, desactívala. Es la mitigación más directa que recogen los propios advisories.
- No mezcles en el mismo VPS datos sensibles y entornos de laboratorio con acceso amplio para terceros.
- Trata los VPS ultra baratos como lo que son: espacio compartido con desconocidos, no un mini-dedicado con garantías enterprise.
La industria del hosting lleva meses justificando subidas de precio por la escasez de RAM. Perfecto, lo entiendo. Pero subir la factura sin subir la transparencia sobre parches de hipervisor es vender seguridad por osmosis. Zapscape no inventa el problema; lo pone en el correo de soporte que probablemente no vas a escribir.
Si mañana tu proveedor te confirmara por escrito que el hipervisor sigue sin parchear pero te ofreciera un 15% de descuento para renovar antes de fin de mes, ¿renovarías igual confiando en que «total, nadie ataca VPS de pymes»?