Una falla de KVM de Linux de hace 16 años permite que las máquinas virtuales invitadas escapen al host en sistemas Intel y AMD x86

Se puede activar un error de uso después de la liberación en el hipervisor KVM de Linux desde una máquina virtual invitada para corromper el estado de la página oculta del kernel host que lo ejecuta.

Apodado ‘Januscape‘ y rastreado como CVE-2026-53359la falla se encuentra en el código MMU oculto que KVM comparte tanto en Intel como en AMD. La prueba de concepto pública hace que el anfitrión entre en pánico; El investigador afirma que un exploit separado e inédito convierte el mismo error en la ejecución completa del código host.

investigador de seguridad Hyunwoo Kim (@v4bel) encontró e informó el error. Describió a Januscape como el primer exploit de huésped a host que se puede activar tanto en Intel como en AMD, hasta donde el público sabe. El defecto pasó desapercibido durante aproximadamente 16 años.

Según Kim, el exploit se utilizó como envío de día cero en kvmCTF de Googleel programa de recompensas por vulnerabilidades de KVM controladas que ofrece hasta 250 000 dólares por escapadas completas de invitado a anfitrión.

Cómo funciona

Para ejecutar una máquina virtual, KVM mantiene su propio conjunto privado de tablas de páginas que reflejan el diseño de la memoria del invitado. Cuando necesita una de estas páginas de seguimiento, busca una existente para reutilizarla.

El problema: los comparó solo por la dirección de memoria e ignoró qué tipo de página de seguimiento estaba tomando. Dos tipos diferentes pueden compartir la misma dirección pero realizar trabajos completamente diferentes, por lo que KVM a veces reutiliza el tipo incorrecto.

Ciberseguridad

Esa confusión codifica los registros internos de KVM sobre qué página pertenece y dónde, y una vez que esos registros son incorrectos, algo tiene que ceder.

La mayoría de las veces, el núcleo se da cuenta del desorden y se apaga en el acto para evitar causar daños. Ese bloqueo es lo que desencadena la demostración pública: un invitado puede derribar todo el host, derribando con él a todas las demás máquinas virtuales de esa máquina.

El caso más raro y peor ocurre cuando la página de seguimiento liberada se entrega para otro uso antes de que el kernel se limpie. Luego, la limpieza escribe un valor en la memoria que ya no posee. Un atacante solo controla dónde llega esa escritura, no lo que se escribe, pero incluso ese punto de apoyo limitado se puede convertir en código ejecutable en el host.

La falla se comporta igual en los chips Intel y AMD; sólo el paso final y más difícil de convertirlo en control total requiere un trabajo diferente en cada uno.

¿Quién se ve afectado?

El código vulnerable ha estado presente desde cometer 2032a93d66fa en agosto de 2010 (era del kernel 2.6.36) y fue reparado por cometer 81ccda30b4e8se fusionó con mainline el 19 de junio de 2026.

El ataque requiere dos cosas por parte del huésped: raíz dentro de la VM, una condición común en instancias de nube alquiladas, y virtualización anidada expuesta por el host. Incluso en hosts que ejecutan hardware EPT o NPT de forma predeterminada, la virtualización anidada obliga a KVM a retroceder a través de la MMU oculta heredada, que es donde se encuentra el error.

El exploit no necesita la cooperación de QEMU ni de ningún VMM del espacio de usuario. Es puramente un error de KVM en el kernel.

La preocupación práctica es cualquier entorno x86 que aloje invitados que no sean de confianza y con la virtualización anidada habilitada. Un atacante que alquila una sola instancia de este tipo puede provocar pánico en el host y desactivar todas las demás máquinas virtuales de la misma máquina física.

Kim dijo que el exploit completo retenido ejecuta código como root en el host, lo que expondría a otros invitados en la misma máquina a ese acceso de root. En distribuciones como RHEL, donde /dev/kvm se puede escribir en todo el mundo (0666), Kim notó que el mismo error también podría servir como una escalada de privilegios locales a la raíz, aunque la ruta de invitado a host es el uso de mayor impacto.

Unos meses muy ocupados para un investigador

Januscape es la tercera revelación de Kim sobre un exploit del kernel de Linux en aproximadamente dos meses. En mayo de 2026, reveló Dirty Frag (CVE-2026-43284 / CVE-2026-43500), una cadena de vulnerabilidad de escritura en caché de página que ofrece raíz determinista en la mayoría de las distribuciones principales, extendiendo la misma clase de error que Dirty Pipe y Copy Fail.

En junio publicó SU paisaje (CVE-2026-46316), el primer escape de huésped a host demostrado públicamente en KVM/arm64, que explota una condición de carrera en el controlador de interrupción virtual. Januscape ahora añade el lado x86; el mismo disparador se activa tanto en Intel como en AMD, y el PoC lleva una ruta de código separada para cada proveedor.

Ciberseguridad

Google lanzó kvmCTF en 2024 específicamente porque KVM sustenta tanto a Android como a Google Cloud. Un uso-después libre de paginación oculta KVM x86 independiente (CVE-2026-46113) que involucraba una discrepancia de rmap relacionada pero distinta, se solucionó en mayo de 2026.

Eso hace que dos MMU en la sombra se liberen en la misma ruta de código heredado en dos meses.

Qué hacer

La solución es una adición de una línea a kvm_mmu_get_child_sp(): la condición de reutilización ahora verifica role.word junto con gfn, por lo que una página oculta solo se reutiliza cuando tanto el número de fotograma como el rol coinciden. El mantenedor de KVM Paolo Bonzini escribió el parche.

Versiones estables fijas enviadas el 4 de julio de 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 y 5.10.260. NVD aún no ha asignado una puntuación CVSS; no esperes uno.

Si opera un host KVM x86 que acepta invitados multiinquilino con virtualización anidada, confirme que su kernel incluya la confirmación 81ccda30b4e8. Los backports de distribución pueden contener la solución con un número de versión diferente, así que verifique el registro de cambios del paquete en lugar de confiar solo en uname -r.

Si no puede parchear inmediatamente, deshabilitar la virtualización anidada (kvm_intel.nested=0 o kvm_amd.nested=0) elimina la ruta de ataque para invitados que no son de confianza. Los hosts ARM64 no se ven afectados por Januscape; ITScape (CVE-2026-46316) es un problema separado de KVM/arm64.

La PoC pública demuestra un pánico de host confiable por parte de un invitado con un módulo de kernel cargable y segundos o minutos de carrera. Trate los hosts KVM x86 expuestos con virtualización anidada como objetivos de parches de alta prioridad.

Nueve fallas críticas de KVM IP permiten acceso raíz no autenticado a través de cuatro proveedores – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han advertido sobre los riesgos que plantean los dispositivos IP KVM (teclado, vídeo, ratón sobre protocolo de Internet) de bajo coste, que pueden otorgar a los atacantes un amplio control sobre los hosts comprometidos.

Las nueve vulnerabilidades, descubiertas por eclipsioabarcan cuatro productos diferentes: GL-iNet Comet RM-1, Angeet/Yeeso ES3 KVM, Sipeed NanoKVM y JetKVM. Los más graves permiten que actores no autenticados obtengan acceso de root o ejecuten código malicioso.

«Los temas comunes son condenatorios: falta de validación de firma de firmware, falta de protección de fuerza bruta, controles de acceso rotos e interfaces de depuración expuestas», investigadores Paul Asadoorian y Reynaldo Vasquez García. dicho en un análisis.

Ciberseguridad

Dado que los dispositivos IP KVM permiten el acceso remoto al teclado, la salida de video y la entrada del mouse de la máquina de destino a nivel BIOS/UEFI, la explotación exitosa de las vulnerabilidades en estos productos puede exponer los sistemas a posibles riesgos de adquisición, socavando los controles de seguridad implementados. La lista de deficiencias es la siguiente:

  • CVE-2026-32290 (Puntuación CVSS: 4,2) – Una verificación insuficiente de la autenticidad del firmware en GL-iNet Comet KVM (se está planificando una solución)
  • CVE-2026-32291 (Puntuación CVSS: 7,6) – Una vulnerabilidad de acceso raíz al receptor-transmisor asíncrono universal (UART) en GL-iNet Comet KVM (se está planificando una solución)
  • CVE-2026-32292 (Puntuación CVSS: 5,3) – Una vulnerabilidad de protección de fuerza bruta insuficiente en GL-iNet Comet KVM (corregido en la versión 1.8.1 BETA)
  • CVE-2026-32293 (Puntuación CVSS: 3.1) – Un aprovisionamiento inicial inseguro a través de una vulnerabilidad de conexión a la nube no autenticada en GL-iNet Comet KVM (corregido en la versión 1.8.1 BETA)
  • CVE-2026-32294 (Puntuación CVSS: 6.7) – Una vulnerabilidad de verificación de actualización insuficiente en JetKVM (corregido en la versión 0.5.4)
  • CVE-2026-32295 (Puntuación CVSS: 7.3) – Una vulnerabilidad de limitación de velocidad insuficiente en JetKVM (corregido en la versión 0.5.4)
  • CVE-2026-32296 (Puntuación CVSS: 5.4) – Una vulnerabilidad de exposición del punto final de configuración en Sipeed NanoKVM (corregido en NanoKVM versión 2.3.1 y NanoKVM Pro versión 1.2.4)
  • CVE-2026-32297 (Puntuación CVSS: 9,8) – Autenticación faltante para una vulnerabilidad de función crítica en Angeet ES3 KVM que conduce a la ejecución de código arbitrario (no hay solución disponible)
  • CVE-2026-32298 (Puntuación CVSS: 8,8) – Una vulnerabilidad de inyección de comandos del sistema operativo en Angeet ES3 KVM que conduce a la ejecución de comandos arbitrarios (no hay solución disponible)

«Estos no son días cero exóticos que requieren meses de ingeniería inversa», señalaron los investigadores. «Estos son controles de seguridad fundamentales que cualquier dispositivo en red debe implementar. Validación de entrada. Autenticación. Verificación criptográfica. Limitación de velocidad. Estamos viendo la misma clase de fallas que afectaron a los primeros dispositivos IoT hace una década, pero ahora en una clase de dispositivo que proporciona el equivalente de acceso físico a todo lo que se conecta».

Un adversario puede utilizar estos problemas como arma para inyectar pulsaciones de teclas, arrancar desde medios extraíbles para evitar el cifrado del disco o las protecciones de arranque seguro, eludir las pantallas de bloqueo y los sistemas de acceso y, lo que es más importante, permanecer sin ser detectado por el software de seguridad instalado en el nivel del sistema operativo.

Ciberseguridad

Esta no es la primera vez que se revelan vulnerabilidades en dispositivos IP KVM. En julio de 2025, el proveedor ruso de ciberseguridad Positive Technologies señaló cinco defectos en conmutadores ATEN International (CVE-2025-3710, CVE-2025-3711, CVE-2025-3712, CVE-2025-3713 y CVE-2025-3714) que podrían allanar el camino para la denegación de servicio o la ejecución remota de código.

Es más, los trabajadores de TI norcoreanos que residen en países como China han utilizado conmutadores KVM IP como PiKVM o TinyPilot para conectarse de forma remota a computadoras portátiles proporcionadas por la empresa alojadas en granjas de computadoras portátiles.

Como mitigaciones, se recomienda aplicar la autenticación multifactor (MFA) cuando sea compatible, aislar los dispositivos KVM en una VLAN de administración dedicada, restringir el acceso a Internet, usar herramientas como Shodan para verificar la exposición externa, monitorear el tráfico de red inesperado hacia/desde los dispositivos y mantener el firmware actualizado.

«Un KVM comprometido no es como un dispositivo IoT comprometido ubicado en su red. Es un canal directo y silencioso hacia cada máquina que controla», dijo Eclypsium. «Un atacante que compromete el KVM puede ocultar herramientas y puertas traseras en el propio dispositivo, reinfectando constantemente los sistemas host incluso después de la reparación».

«Dado que algunas actualizaciones de firmware carecen de verificación de firma en la mayoría de estos dispositivos, un atacante de la cadena de suministro podría alterar el firmware en el momento de la distribución y hacer que persista indefinidamente».