Xen Orchestra: un fallo de autenticación explotado da derechos de administrador sobre la virtualización XCP-ng

Vigilancia cibernética de Top-Secured: análisis independiente basado en las fuentes citadas más abajo. Top-Secured no está afiliado a las empresas mencionadas y nunca le pedirá sus datos bancarios ni sus contraseñas.

Vates ha corregido un fallo crítico en Xen Orchestra, la consola web que gestiona los hosts XCP-ng, y advierte de que ya se está explotando. Basta una cookie manipulada para hacerse pasar, sin contraseña, por un usuario existente, normalmente un administrador. Las versiones 6.9.2 y 6.10.1 lo corrigen; las consolas expuestas también deben revisarse.

Qué ha pasado

El 10 de noviembre de 2026, la empresa francesa Vates, creadora de Xen Orchestra y XCP-ng, publicó el aviso VSA-2026-062, de gravedad crítica, e indica que el fallo se está explotando activamente. En el momento de la publicación no tenía identificador CVE ni puntuación CVSS. Las versiones corregidas salieron ese mismo día.

El defecto está en la autenticación de la API REST. Una cookie cuyo token es un objeto vacío manipulado, en lugar de una cadena de texto, llega sin comprobar a la búsqueda de tokens. Esta devuelve entonces el primer token válido guardado por Xen Orchestra, y la petición se trata como si viniera de su propietario. A partir de ahí, el atacante puede listar tokens de inicio de sesión reutilizables y actuar con derechos de administrador. La corrección, integrada en GitHub, rechaza cualquier token que no sea una cadena no vacía.

Quién está en riesgo

Todas las instalaciones de Xen Orchestra anteriores a 6.9.2 (canal stable) y 6.10.1 (canal latest), ya sea el appliance XOA o una compilación desde el código fuente. Según Vates, tomar el control de la consola puede llevar a la ejecución de código en los pools gestionados y a acceso root en los hosts XCP-ng. Las consolas accesibles desde Internet son las primeras en la línea de fuego.

Qué hacer ahora

1. Actualice: XOA a 6.9.2 (stable) o 6.10.1 (latest), es decir xo-server 5.211.2 o 5.213.1; las instalaciones desde el código fuente, al último commit de master y después recompilar.
2. Saque la consola de Internet: solo una red de administración dedicada o una VPN.
3. Filtre: bloquee las direcciones IP y la dirección Tor que figuran en el aviso y, en su proxy inverso, las peticiones cuya cookie authenticationToken empiece por j:. Vates advierte de que otras codificaciones pueden eludir una regla así.
4. Busque rastros: un ataque logrado no deja nada en el registro de autenticación. Busque una VM llamada pivot2 y, en cada host XCP-ng, ejecute xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', zgrep -- '-serial file:' /var/log/xensource.log* y ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*.
5. Si hay compromiso: cambie todos los secretos conocidos por la plataforma (cuentas root, secreto del pool, destinos de copia de seguridad, proxies, usuarios, secretos OTP, servidor de correo) y, como recomienda Vates, reinstale en lugar de limpiar.

Nuestra opinión

La consola de un hipervisor guarda las llaves de todas las máquinas virtuales: es el servidor más sensible de la empresa y no debe estar en Internet. Parchear no basta esta vez: como el ataque no deja rastro de conexión, solo una revisión de los hosts dirá si alguien ya entró.

Fuentes

• Vates — VSA-2026-062: Empty-object login token
• GitHub (vatesfr/xen-orchestra) — fix(xo-server): validate authentication token IDs, PR #10748
• The Hacker News — Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access

Cómo elegimos, verificamos y redactamos nuestros análisis →