Un escape de VM sin CVE ni parche: qué alcanza root en un nodo de Proxmox

Hay un aviso de fuga de invitado a host en KVM que no se puede parchear, porque todavía no existe el parche ni el número que lo identifique. Lo que sí se puede medir hoy es hasta dónde llegaría una fuga así en un clúster de Proxmox. Son menos pasos de los que la gente cuenta.

El martes 6 de octubre de 2026, The Register contó que el investigador Paulos Yibelo publicó en X «a screenshot of a bug bounty award he won for discovering what he described as "Full VM escape zeroday (guest>host root in industry standard hypervisors)!"», y que el consejero delegado de Vercel, Guillermo Rauch, escribió: «We've confirmed a KVM 0day through our Vercel Sandbox bounty program». El mismo artículo explica por qué esto nos toca a quienes vivimos de la virtualización, y nombra la casa por su nombre: «Enterprise virtualization players Nutanix, HPE, and Proxmox also rely on KVM».

Lo que se sabe y lo que no

En Proxmox, el salto es uno

Cuando se lee «guest>host root», la cuenta mental de mucha gente son dos peldaños: primero sales del invitado y caes en el proceso del hipervisor, luego escalas a root en la máquina. En Proxmox VE ese segundo peldaño no existe, y lo dice su propia documentación de QEMU/KVM:

QEMU inside Proxmox VE runs as a root process, since this
is required to access block and PCI devices.

La misma página explica el motivo: «From the perspective of the host system where QEMU is running, QEMU is a user program which has access to a number of local resources like partitions, files, network cards». Un programa con acceso a disco y a PCI necesita root, y la decisión es defendible. Lo que cambia es la aritmética de la noticia: quien salga del invitado aterriza directamente con el usuario que manda en el nodo, sin un rellano intermedio donde tu telemetría pueda verlo tropezar.

Y la carpeta a la que llega no es de ese nodo

Proxmox guarda su configuración en pmxcfs, que su documentación define como «a database-driven file system for storing configuration files, replicated in real time to all cluster nodes using corosync». Es la carpeta /etc/pve que ves en cada nodo, y es la misma en todos. Dentro hay una subcarpeta con permisos propios: «Files below the following paths are only accessible by root: /etc/pve/priv/» (y también /etc/pve/nodes/${NAME}/priv/). Justo el usuario donde acaba de aterrizar la fuga.

Las diez líneas, tal como las lista la documentación

Esto es lo que esa documentación enumera ahí dentro, con la descripción que ella misma le pone a cada fichero. Lo único que hemos tocado es expandir el prefijo: la tabla original los escribe como priv/authkey.key y aquí van con la ruta entera— y partir en dos líneas las dos descripciones que no cabían de largas.

/etc/pve/priv/authkey.key        Private key used by ticket system
/etc/pve/priv/authorized_keys   SSH keys of cluster members for authentication
/etc/pve/priv/ceph*             Ceph authentication keys and associated capabilities
/etc/pve/priv/known_hosts       SSH keys of the cluster members for verification
/etc/pve/priv/lock/*            Lock files used by various services to ensure
                                safe cluster-wide operations
/etc/pve/priv/pve-root-ca.key   Private key of cluster CA
/etc/pve/priv/shadow.cfg        Shadow password file for PVE Realm users
/etc/pve/priv/storage/<STORAGE-ID>.pw
                                Contains the password of a storage in plain text
/etc/pve/priv/tfa.cfg           Base64-encoded two-factor authentication configuration
/etc/pve/priv/token.cfg         API token secrets of all tokens

La única de las diez que se rota sola

La primera línea tiene una particularidad que cambia cómo se lee la lista entera, y para verla hay que salir de la documentación e ir al código. authkey.key es la clave con la que el sistema de tickets firma las sesiones de la interfaz y de la API. Proxmox la rota solo: en PVE::AccessControl hay dos constantes fijas, my $ticket_lifetime = 3600 * 2; # 2 hours y my $authkey_lifetime = 3600 * 24; # rotate every 24 hours, y una función rotate_authkey() que se dispara sola cuando la clave caduca. De los diez ficheros de esa carpeta, nueve son material de credenciales y uno, lock/*, son ficheros de bloqueo que no hay que rotar. De esos nueve, authkey.key es el único que no tienes que meter en ningún procedimiento: se renueva sola cada 24 horas, con cinco minutos de gracia para la clave anterior y tickets que viven dos horas, y la rotación se dispara cuando el sistema vuelve a necesitar firmar, no por reloj. Las otras ocho siguen valiendo mañana, y el mes que viene.

Y ninguno de esos ficheros pertenece al nodo donde cayó el invitado. pmxcfs los replica en tiempo real a todos. Un nodo comprometido es, por construcción, la carpeta de secretos del clúster entero, tengas tres nodos o doce, y da igual en cuál estuviera la máquina virtual que falló. Lo que nos costó un post entero contar en términos de lo que cuesta root ajeno en un hipervisor aquí se ve de un vistazo, en una tabla de la documentación que lleva años publicada.

La línea que más cuesta leer dos veces

Es la octava: «Contains the password of a storage in plain text». Si tu almacenamiento de copias es un Proxmox Backup Server, ahí está la credencial con la que el clúster habla con él. Y la documentación de almacenamiento coloca en esa misma carpeta dos vecinos: la clave de cifrado, «saved in a file under /etc/pve/priv/storage/<STORAGE-ID>.enc», y la pública maestra, en .master.pem. La contraseña de las copias y la clave para descifrarlas, el mismo directorio y el mismo permiso.

Qué puede hacer esa credencial cuando alguien se la lleva ya lo contamos, y no lo vamos a reimprimir: el reparto de permisos de borrado y el token de copia que no puede borrar están en Proxmox Protected no es un candado, de agosto, donde además decíamos que la retención tiene que vivir en el servidor de copias y no en el cliente; y la credencial de consola que alcanzaba más de lo que decía su nombre, ayer. Lo que allí no está, y es lo único que añadimos aquí, es el modo de fallo: si recortas el token pero dejas la retención configurada en el almacenamiento del clúster, el trabajo de copia intentará podar al final y terminará en error de permisos esa misma noche. Mover la retención va antes que recortar el token, no después.

El entregable: la lista de rotación, línea a línea

Si la carpeta es del clúster y no del nodo, entonces el día que un solo nodo se dé por comprometido —por esta fuga, por una credencial filtrada o por un disco que se fue a reparar sin borrar— no se rota una contraseña: se rota la lista entera de arriba. Escribir esa lista cuesta una tarde en frío y un fin de semana en caliente. Cada línea tiene su propio coste y conviene estimarlo antes:

El fallo es inevitable, la avería es una decisión de diseño. Que un hipervisor tenga alguna vez una fuga de invitado a host no lo decides tú: los ha tenido todos. Lo que decides es cuánto tardas en saber qué hay que cambiar cuando pase, y eso se escribe hoy, sin parche y sin CVE, mirando una tabla de diez líneas.

Lo que no afirmamos

Con un clúster pequeño y la consola a mano, la lista de rotación la escribe tu gente en una tarde. Se complica cuando nadie recuerda qué tokens de API hay vivos, cuando el servidor de copias lo montó alguien que ya no está, o cuando la red de gestión comparte VLAN con las máquinas de los usuarios porque así arrancó el proyecto. Decidir qué alcanza cada credencial y cada segmento, y dejarlo escrito, es trabajo de zero trust; cronometrar la recuperación contando lo que esa rotación cuesta es trabajo de disaster recovery. Vendemos los dos, así que léelo con el conflicto de interés por delante. Si tu gente ya tiene la lista escrita, cierra esta pestaña. Si al leer la tabla de diez líneas has pensado «de ésta no sabría ni por dónde empezar», hablémoslo.

Fuentes