Omisión de autenticación en Xen Orchestra da acceso de administrador y puede permitir la toma de control de hosts XCP-ng

Qué ocurrió

El 10 de noviembre de 2026, Vates publicó el aviso de seguridad VSA-2026-062 sobre una omisión de autenticación crítica en Xen Orchestra. Xen Orchestra es la interfaz de gestión web para entornos de virtualización XCP-ng. Todavía no se ha asignado un ID de CVE ni una puntuación CVSS.

La falla está en la forma en que la API REST gestiona la cookie de inicio de sesión. Una cookie con el valor authenticationToken=j:%7B%7D se interpreta como un objeto vacío ({}). Este objeto se pasa a la comprobación del token sin verificar que sea una cadena. La búsqueda del token devuelve entonces el primer token almacenado, y la solicitud se autentica como el propietario de ese token, siempre que el token no haya caducado. Mediante el endpoint /rest/v0/users/me/authentication_tokens, un atacante puede leer después identificadores de tokens de inicio de sesión reutilizables.

Según Vates, un atacante puede usar esto para realizar acciones con privilegios de administrador en Xen Orchestra sin credenciales. Esto puede derivar en la ejecución arbitraria de código en los pools gestionados y en la toma de control completa de los hosts XCP-ng como root.

Vates indica que la vulnerabilidad se está explotando activamente por un actor de amenazas que opera desde 91.211.251.112:8001 y desde una dirección Tor (véase más abajo). No se sabe cuándo comenzaron los ataques ni si la falla se explotó antes de publicarse la corrección. La falla fue descubierta por Filip Magic y Christoffer Olsen de TDC NET Security.

Quién está afectado

• Xen Orchestra anterior a 6.9.1 (canal estable) y anterior a 6.10.0 (canal latest)
• los paquetes xo-server correspondientes anteriores a 5.211.2 (estable) y 5.213.1 (latest)
• Xen Orchestra Appliance (XOA)

El atacante necesita acceso de red a la interfaz web de Xen Orchestra. Las instancias accesibles desde internet tienen el mayor riesgo. Los hosts XCP-ng también están en riesgo porque Xen Orchestra los gestiona. Si no utiliza Xen Orchestra, este aviso no le afecta.

Qué hacer ahora

1. Actualice Xen Orchestra. Instale Xen Orchestra 6.9.1 en el canal estable o 6.10.0 en el canal latest. Incluyen xo-server 5.211.2 (estable) o 5.213.1 (latest). Haga primero una copia de seguridad de la configuración de Xen Orchestra. Después de la actualización, confirme que xo-server está en ejecución y que puede iniciar sesión y ver sus pools.
2. Restrinja el acceso. No exponga Xen Orchestra a internet. Vates recomienda colocarlo en una red de gestión dedicada, accesible solo para administradores, por ejemplo a través de una VPN.
3. Bloquee la infraestructura del atacante. Vates recomienda reglas de filtrado de entrada y salida para 91.211.251.112 y bloquear el tráfico Tor, de modo que los hosts no puedan alcanzar ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. Si no puede actualizar de inmediato, bloquee el token vacío en un WAF o en un proxy inverso situado delante de Xen Orchestra. Filtre los patrones de cookie authenticationToken=j:{} y authenticationToken=j:%7B%7D.
5. Compruebe si hay un compromiso (véase la siguiente sección). Si encuentra indicios de compromiso, cambie todas las contraseñas y secretos utilizados en su entorno de Xen Orchestra y XCP-ng, e investigue los hosts y las VM afectados.

Cómo comprobar si está afectado

Primero, revise la versión de Xen Orchestra en la interfaz web o en el appliance. Si es anterior a 6.9.1 (estable) o 6.10.0 (latest), el sistema es vulnerable.

Vates y los informes publicados enumeran estos indicadores de compromiso para la campaña de ataque conocida:

• solicitudes HTTP que contienen authenticationToken=j:%7B%7D o authenticationToken=j:{}
• conexiones a 91.211.251.112:8001 o a ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• una máquina virtual llamada pivot2
• máquinas virtuales configuradas con hvm_serial: file
• los archivos /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 y /.ustar6

En los hosts XCP-ng, ejecute las comprobaciones recomendadas por Vates:

xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'

zgrep -- '-serial file:' /var/log/xensource.log*

ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

También busque una VM llamada pivot2, por ejemplo con xe vm-list name-label=pivot2.

Según los informes, Xen Orchestra no registra la cookie manipulada. Solo puede detectarla mediante monitorización HTTP, por ejemplo en los registros de acceso de un proxy inverso situado delante de Xen Orchestra. Revise esos registros y los de su cortafuegos en busca de los patrones de cookie y las direcciones indicadas. Vates señala que estos indicadores pertenecen a una campaña conocida. Otros atacantes pueden dejar rastros diferentes, por lo que no encontrar ninguno de ellos no demuestra que un sistema esté limpio.

Fuentes

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/hackers-exploit-critical-xen-orchestra.html