La memoria de otras máquinas no solo puede leerse, también puede modificarse: en Xen se ha roto el aislamiento entre máquinas virtuales.

La memoria de otras máquinas no solo puede leerse, también puede modificarse: en Xen se ha roto el aislamiento entre máquinas virtuales.

En juego: el control total del servidor físico.

image

En Xen se rompió el aislamiento que debe separar las máquinas virtuales entre sí. Los desarrolladores del hipervisor revelaron el 3 de noviembre dos vulnerabilidades que permiten a un sistema huésped malicioso leer y modificar la memoria RAM ajena. También está en riesgo Dom0, el dominio privilegiado a través del cual el administrador gestiona las demás máquinas en el servidor físico.

El problema se produjo en el mecanismo Grant Copy, que copia datos entre áreas de memoria de máquinas virtuales respetando los permisos concedidos. En operaciones consecutivas Xen reutiliza los resultados de comprobaciones ya realizadas para acelerar el proceso. En el boletín XSA-523 los desarrolladores describieron casos en los que la información almacenada dejó de corresponder con la nueva solicitud.

El primer error, CVE-2026-102703, permite confundir números de página física de memoria con referencias a accesos otorgados. El segundo, CVE-2026-102704, está relacionado con una comprobación mal situada al copiar por número de página. Ese modo solo está permitido para la propia memoria de la parte que realiza la llamada; sin embargo, Xen no siempre respetaba la restricción.

Como resultado, el sistema huésped puede acceder a la memoria de otros dominios, incluido el Dom0 de control, y no solo leer datos, sino sobrescribirlos. Los desarrolladores de XCP-ng admiten la posibilidad de comprometer todo el host tras la violación del aislamiento. Anteriormente se detectó un riesgo similar de escape de la máquina virtual en Linux, pero allí la causa fue un error en la pila de red, no en el propio hipervisor.

Son vulnerables todas las versiones de Xen a partir de la 4.6; las versiones 4.5 y anteriores no se ven afectadas. SUSE evaluó ambos errores con 7,1 puntos según CVSS 3.1 y 8,4 puntos según CVSS 4.0, lo que corresponde a un alto nivel de gravedad. El responsable de XCP-ng, la empresa Vates, calificó el problema como crítico dadas las consecuencias para la infraestructura virtual.

Un detalle inusual de la divulgación está relacionado con el origen del hallazgo. La empresa Anthropic descubrió los errores con ayuda del modelo Claude, tras lo cual Stefan Lipp de Ada Logics verificó el resultado. De forma independiente informó sobre las vulnerabilidades el equipo CodeAnt AI Security Research. Los desarrolladores de Xen no aportan datos sobre ataques reales ni precisan qué nivel de acceso dentro del sistema huésped es necesario para su explotación.

Para XSA-523 se prepararon correcciones, incluidas para las ramas Xen 4.17, 4.18 y 4.19, así como para la versión en desarrollo. Los desarrolladores no proponen una forma de protegerse sin instalar los parches. La plataforma XCP-ng 8.3 recibió el paquete corregido xen-4.17.7-4.2.xcpng8.3 ya el 3 de noviembre. En sistemas con compilaciones más antiguas, la disponibilidad de actualizaciones depende del proveedor.

El equipo de Qubes OS también confirmó la afectación; en esa plataforma las aplicaciones funcionan en entornos virtuales aislados. El Xen corregido 4.19.6-3 para Qubes 4.3 se publicó primero en el repositorio de pruebas y luego se planea trasladarlo al estable. Tras la instalación será necesario reiniciar Dom0. Mientras no se aplique la actualización, el aislamiento de las máquinas virtuales no puede considerarse una frontera fiable de protección.