Fallos del hipervisor Xen permiten que una máquina virtual invitada lea y escriba la memoria de las demás máquinas virtuales del mismo servidor, incluida dom0, la que manda sobre todas. No hace falta romper una contraseña ni engañar a un administrador: el error vive en la operación que copia datos entre dominios.
Xen es una capa de software que reparte un servidor físico entre varias máquinas virtuales y vigila que cada una se quede dentro de su espacio. Corre debajo de plataformas de nube y de sistemas que separan cada tarea en su propio compartimento. Dom0 es el dominio de control: arranca primero, administra a los invitados y trabaja con permisos completos. Entrar en su memoria equivale a quedarse con las llaves del edificio entero.
El Xen Project publicó el aviso XSA-523 el martes 3 de noviembre, ya en su versión 2 y de acceso público. El documento registra dos vulnerabilidades, CVE-2026-102703 y CVE-2026-102704, bajo un título corto: lectura y escritura arbitrarias mediante grant copy, la operación de copia entre dominios. El crédito del hallazgo va para Anthropic, que lo encontró con su modelo Claude; Stephan Lipp, de Ada Logics, validó el descubrimiento, y el equipo de investigación de seguridad de CodeAnt AI lo reportó después por su cuenta.
Dos errores en la copia de memoria entre dominios
Cada invitada declara qué páginas de su memoria pueden tocar las demás, y Xen revisa esos permisos antes de mover un solo dato. Para ahorrar tiempo, cuando una tanda de copias trabaja sobre rangos vecinos de una misma página, Xen guarda los datos ya validados y los reutiliza en las copias siguientes. El aviso explica que las condiciones para volver a validar esa información guardada fallaban en algunos casos, justo en el punto que separa a un inquilino de otro.
El primer fallo, CVE-2026-102703, mezcla dos cosas que nunca debían cruzarse: los números de marco, que identifican páginas físicas de memoria, y las referencias de concesión, que identifican permisos. Con esa confusión abierta, una copia puede terminar apuntando a memoria que el invitado no tiene derecho a tocar, sin que la revisión lo note.
CVE-2026-102704, el segundo fallo, es un control puesto en el sitio equivocado. Copiar por número de marco solo está permitido cuando un dominio trabaja sobre su propia memoria, y la comprobación que debía imponer ese límite quedó mal colocada. El impacto que firma el aviso es directo: un invitado malicioso puede leer y escribir memoria arbitraria perteneciente a otros dominios, dom0 entre ellos.
Están afectadas todas las versiones de Xen desde la 4.6 en adelante; la 4.5 y las anteriores quedan fuera del problema. El documento cierra dos salidas con franqueza: no existe mitigación conocida y la única corrección pasa por aplicar los parches. Tampoco menciona ataques en curso ni precisa qué nivel de acceso necesita el atacante dentro de su propia máquina virtual, dos datos que quedan sin respuesta en el texto oficial.
El otoño ya trajo un aviso parecido en otro hipervisor, el fallo de VMware ESX que dejaba escapar de la máquina virtual, y la lección se repite con otro nombre: el aislamiento se rompe por errores pequeños de comprobación. XCP-ng, plataforma de virtualización construida sobre Xen, resumió el riesgo en sus notas de actualización con una frase seca: un solo invitado comprometido puede romper su aislamiento y apoderarse del anfitrión completo.
Parches listos para 4.17 a 4.19 y reinicio obligatorio
Los parches del aviso cubren desde la rama en desarrollo hasta Xen 4.19, con un juego separado para las versiones 4.18 y 4.17. Para Xen 4.6 a 4.16 el aviso no trae corrección: la 4.16 perdió su soporte de seguridad el 2 de diciembre de 2024, y quien siga operando en esas ramas suma otra tarea, subir de versión, antes de poder cerrar el hueco.
XCP-ng publicó su corrección el mismo 3 de noviembre, el paquete xen-4.17.7-4.2.xcpng8.3, y exige reiniciar los anfitriones para que entre en vigor; Vates, la empresa que respalda esa plataforma, califica el impacto como crítico. Qubes OS, el sistema que encierra aplicaciones y archivos en compartimentos separados apoyados en Xen, confirmó que todas sus versiones y configuraciones con soporte están afectadas. Su arreglo para Qubes 4.3 lleva los paquetes Xen 4.19.6-3 a dom0, pide reiniciar dom0 y obliga a quienes usan Anti Evil Maid a sellar otra vez su frase secreta, porque los binarios nuevos cambian dos valores del arranque medido, PCR18 y PCR19.
The Hacker News detalló el estado de Debian al 4 de noviembre: su registro de seguridad marca el paquete xen como vulnerable en bookworm, trixie y forky, y como corregido en sid, la rama en desarrollo permanente. En Qubes, los paquetes corregidos entraron primero al repositorio de pruebas de seguridad el 3 de noviembre, con el paso al canal estable previsto tras unas dos semanas de pruebas de la comunidad.
XSA-523 queda separado de XSA-500, otro fallo de la misma operación de copia divulgado el 28 de julio y con parches propios. Queda un dato que persigue a cualquier administrador que lea el aviso completo: los fallos del hipervisor Xen, capaces de romper el aislamiento entre máquinas, los encontró un modelo de inteligencia artificial revisando código, la misma clase de herramienta que ya peina programas de nube y de escritorio en busca del próximo error de este tipo.
Fuente: Xen Project
