Durante 16 años, cualquier máquina virtual maliciosa con root sobre un host KVM vulnerable pudo, en teoría, romper la pared que la separaba del servidor físico. Esa pared es una de las promesas fundacionales de la nube: tu VM es tuya y no puede tocar la del vecino ni la del proveedor. Januscape —el nombre que le pusieron a CVE-2026-53359 y su falla hermana CVE-2026-46113— demostró que esa promesa tenía una grieta que nadie vio desde 2010. Se parchó en el kernel mainline de Linux en junio de 2026 y llegó a los kernels estables el 4 de julio. Vamos a ver qué es, por qué necesita dos parches y qué hacer si administrás un host con KVM.
Januscape es una vulnerabilidad crítica de tipo use-after-free en el shadow MMU de KVM, el hipervisor del kernel de Linux. Identificada como CVE-2026-53359 (junto a su falla acoplada CVE-2026-46113), permite que una máquina virtual invitada escape hacia el host físico en sistemas x86 de Intel y AMD. El código vulnerable existía desde agosto de 2010 y recién se corrigió en el kernel mainline el 19 de junio de 2026.
¿Qué hace que un escape de VM sea el peor escenario en la nube?
En un cloud multi-tenant, muchos clientes comparten el mismo servidor físico. La virtualización es lo que garantiza el aislamiento: cada VM cree que tiene la máquina para sí, pero abajo hay un hipervisor (KVM, en Linux) que reparte CPU, memoria y disco entre todas. Un guest-to-host escape rompe justamente eso: el atacante pasa de tener control de su propia VM a tener control del host que corre todas las demás.
Lo que hace a Januscape especialmente serio no es solo lo que permite, sino lo accesible que es el punto de partida:
- Solo necesita root dentro del invitado. Y ese root lo tenés por defecto cuando te asignan una instancia: sos administrador de tu propia VM. No hay que escalar nada previo.
- Afecta a Intel y a AMD. Según los investigadores, es el primer exploit guest-to-host de esta clase disparable de forma confiable en ambas arquitecturas x86, no en una sola.
- Ya hay prueba de concepto pública. Un PoC ejecutado dentro del invitado dispara un kernel panic del host en segundos o minutos (denegación de servicio comprobada); se reclama además ejecución de código con privilegios de root en el host.
- Estuvo 16 años agazapado. El código data de un commit del 1 de agosto de 2010 (kernel 2.6.36 en adelante), así que la ventana de exposición histórica es enorme.
Fue descubierta por el investigador Hyunwoo Kim (@v4bel) y demostrada como zero-day en el programa de bug bounty kvmCTF de Google. A la fecha de su publicación no había evidencia de explotación activa en la naturaleza.
¿Cómo funciona el bug en el shadow MMU de KVM?
Para entender Januscape hay que mirar cómo KVM traduce direcciones de memoria. Cuando el hardware no puede hacerlo solo, KVM mantiene tablas de páginas del lado del host —el shadow MMU— que reflejan (le hacen "sombra" a) las tablas de páginas del invitado. Cada estructura de esas se llama shadow page y lleva un role: un campo que dice qué tipo de mapeo representa (por ejemplo, un mapeo directo de una página grande de 2 MB, o una sombra indirecta de una tabla de páginas del invitado).
El bug es una confusión entre dos shadow pages que representan cosas distintas. La secuencia, simplificada:
- El invitado crea un mapeo —por ejemplo una página grande de 2 MB— y KVM construye una shadow page directa para él.
- El invitado reescribe ese mapeo hacia un camino de tabla de páginas de 4 KB, de forma asincrónica, por fuera del recorrido normal.
- KVM reutiliza la shadow page vieja. Al buscar una estructura existente para reciclar, la rutina compara únicamente el guest frame number (GFN, la dirección que representa) y ve que coincide, pero no compara el
role. Reutiliza una página "directa" donde ahora debería haber una "indirecta". - La limpieza falla. Como la interpretación quedó desalineada, el cálculo de frame durante la limpieza no encuentra la entrada del mapa inverso (reverse-map o rmap) y no la borra.
- Use-after-free. La shadow page se libera, pero la entrada rmap obsoleta sobrevive apuntando a memoria ya liberada. Un recorrido posterior del rmap desreferencia esa memoria muerta: ahí está el escape.
El parche es conceptualmente simple: al buscar una shadow page para reutilizar, KVM ahora compara también role.word, no solo el GFN. Si el rol no coincide, en vez de reciclar la página la invalida (zap) y construye una nueva.
¿Por qué hacen falta dos CVE (53359 y 46113)?
Este es el punto que más confunde y el más importante desde lo operativo: parchear solo CVE-2026-53359 no te deja seguro. Son dos condiciones distintas de "shadow page rancia" que hay que cerrar juntas:
- CVE-2026-46113 — desajuste de GFN. KVM reutiliza una shadow page construida para un guest frame number equivocado; la nueva entrada queda registrada fuera del rango que KVM revisa al limpiar. Se corrigió antes (llegó a estables antes) agregando un chequeo de frame number.
- CVE-2026-53359 (Januscape) — desajuste de
role. El caso que vimos arriba: el GFN coincide pero el rol (directo vs. indirecto) no. El parche agrega la comparación del rol.
Los dos commits tienen que estar presentes en el kernel que estás corriendo para remediar la clase completa de bugs. En mainline son 0cb2af2ea66a (CVE-2026-46113) y 81ccda30b4e8 (Januscape, mergeado el 19 de junio de 2026). Si tu distro backporteó uno solo, seguís expuesto.
¿Mi servidor está afectado? El detalle de la virtualización anidada
Acá viene el matiz que salva —o condena— a muchos hosts. Los procesadores modernos traducen memoria de invitados por hardware: EPT en Intel, NPT en AMD. Cuando esa aceleración está activa, KVM ni siquiera pasa por el shadow MMU de software donde vive Januscape.
El problema es la virtualización anidada (nested virtualization): correr VMs dentro de VMs. Ese escenario obliga a KVM a volver al viejo shadow MMU legacy, y ahí es donde reaparece el bug. Por eso un host puede verse totalmente moderno y estar igual dentro del radio de impacto.
En términos prácticos, mirá tu situación:
- Sos tenant de una VM en un cloud gestionado. El host físico lo parcha tu proveedor; no es algo que apliques vos desde adentro de tu instancia. Vale seguir el aviso de tu proveedor, pero el arreglo está de su lado.
- Administrás tu propio host KVM (por ejemplo un Cloud Server donde vos corrés máquinas virtuales o labs con nested virt). Sos el host: te toca parchear.
- No usás virtualización anidada. Con EPT/NPT y nested apagado, la superficie de ataque de esta clase se reduce drásticamente, pero parchear sigue siendo lo correcto.
¿Qué podés hacer hoy para protegerte?
Si administrás un host con KVM, en orden de prioridad:
1. Verificá tu versión de kernel. El fix llegó a los kernels estables el 4 de julio de 2026. Revisá con:
uname -rY compará contra las series parcheadas:
| Serie | Versión con el fix |
|---|---|
| 7.1.x | 7.1.3 |
| 6.18.x | 6.18.38 |
| 6.12.x | 6.12.95 |
| 6.6.x | 6.6.144 |
| 6.1.x | 6.1.177 |
| 5.15.x | 5.15.211 |
| 5.10.x | 5.10.260 |
Si usás un kernel de distro (RHEL, Ubuntu, Debian, AlmaLinux, Rocky), verificá con tu vendor que el backport incluya los dos commits, no solo uno. El número de versión de tu distro no siempre coincide con el mainline.
2. Actualizá y reiniciá (o aplicá parcheo en caliente si tu stack lo soporta). Ejemplo en Debian/Ubuntu:
sudo apt update && sudo apt upgrade
# revisá que el kernel nuevo esté instalado, luego:
sudo reboot3. Si no podés parchear ya y no necesitás nested virt, desactivala. Es la mitigación más directa mientras tanto. En Intel:
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.confEn AMD:
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.confVerificá el estado actual del parámetro:
for p in /sys/module/kvm_intel/parameters/nested /sys/module/kvm_amd/parameters/nested; do
[ -e "$p" ] && printf "%s=%s\n" "$p" "$(tr -d '\n' < "$p")"
done4. Si el host no corre VMs, no cargues KVM. Bloquear el módulo elimina la superficie por completo:
echo "install kvm_intel /bin/false" | sudo tee /etc/modprobe.d/disable-kvm.conf5. Endurecé el acceso a /dev/kvm. El exploit necesita ejecutarse desde un invitado; limitar quién puede crear VMs (permisos 0660 vía udev, grupos acotados) reduce el conjunto de actores capaces de disparar la falla en un host con múltiples usuarios.
Si venís siguiendo la seguridad del kernel de Linux, Januscape entra en la misma familia de sustos recientes que ya cubrimos: vale leerlos como complemento —Bad Epoll (CVE-2026-46242) y DirtyClone (CVE-2026-43503), dos vías a root en Linux que también dependían de parchear a tiempo.
Preguntas frecuentes
¿Januscape se explota en la nube sin hacer nada especial?
Necesita dos condiciones: root dentro del invitado (que tenés por defecto en tu propia VM) y que el host tenga virtualización anidada activa, lo que lo empuja al shadow MMU vulnerable. Sin nested virt, la superficie de esta clase se reduce mucho.
¿Alcanza con parchear CVE-2026-53359?
No. Hay que aplicar también CVE-2026-46113. Son dos condiciones distintas de shadow page obsoleta; el kernel necesita los commits 81ccda30b4e8 y 0cb2af2ea66a presentes para cerrar la clase completa.
¿Qué versión de kernel corrige el problema?
El fix se mergeó en mainline el 19 de junio de 2026 y llegó a los kernels estables el 4 de julio: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 y 5.10.260. En kernels de distro, confirmá el backport con tu vendor.
¿Sirve desactivar la virtualización anidada como mitigación?
Sí, es la mitigación temporal más efectiva si no la necesitás: options kvm_intel nested=0 (Intel) o options kvm_amd nested=0 (AMD). No reemplaza al parche, pero corta la ruta al shadow MMU legacy mientras planificás la actualización.
¿Afecta solo a Intel o también a AMD?
A ambos. Januscape es notable justamente porque es disparable de forma confiable tanto en Intel (EPT) como en AMD (NPT) cuando la virtualización anidada está activa, algo poco común en escapes guest-to-host previos.
¿Fue explotado en ataques reales?
Al momento de su divulgación no había evidencia pública de explotación en la naturaleza. Sí existe prueba de concepto que genera un kernel panic del host en minutos, así que el riesgo de denegación de servicio es concreto y la ventana para parchear es corta.
Fuentes
- The Hacker News — 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host
- SecurityWeek — Linux Kernel Vulnerability Allows VM Escape on Intel and AMD Systems
- TuxCare — Januscape Exposes the KVM Shadow Paging Bug That Kept Coming Back
- byteiota — Januscape CVE-2026-53359: Patch This Linux KVM Escape Now
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
