# Xen Orchestra VSA-2026-062, una cookie vacía da root en XCP-ng

> Vates confirma explotación activa de VSA-2026-062 en Xen Orchestra: una cookie vacía salta la autenticación y da root en XCP-ng. Cómo detectarlo.
> Por José Maldonado · Ciberseguridad · 2026-11-11

Xen Orchestra es el panel desde el que proveedores de hosting, departamentos de TI y una legión de homelabs gobiernan sus máquinas virtuales. Desde el 10 de noviembre, ese panel tiene una puerta abierta que no pide contraseña: basta con enviar una cookie con un objeto JSON vacío para que el sistema devuelva el primer token de sesión que encuentre y trate al visitante como su dueño. Vates, la empresa francesa que desarrolla el software, clasifica el fallo como crítico y confirma que hay alguien explotándolo ahora mismo contra instalaciones reales.

El fallo se llama VSA-2026-062, todavía no tiene identificador CVE ni puntuación CVSS, y afecta a Xen Orchestra y a la Xen Orchestra Appliance. El salto de autenticación no se queda en un panel de administración: desde ahí el atacante puede ejecutar código en los pools gestionados y tomar el control completo de un nodo XCP-ng con privilegios de root. Es decir, el mismo servidor que aloja las máquinas virtuales de un cliente puede acabar sirviendo para atacar a los demás.

La parte incómoda no es el error de programación, es el contexto. Exponer el panel de gestión a internet es una costumbre extendida porque resulta cómodo para administrar desde casa, y este fallo convierte esa comodidad en una puerta de entrada silenciosa. Vates avisa de que la explotación no genera ninguna entrada identificable en los registros de la aplicación: quien quiera saber si le han entrado tendrá que mirar el tráfico HTTP, no los logs.

## Una cookie vacía que se convierte en administrador

El mecanismo es tan simple que cuesta creer que funcionara. Xen Orchestra acepta peticiones a su API REST con un token de autenticación dentro de una cookie. El código que interpreta esa cookie convierte \`authenticationToken=j:%7B%7D\` en un objeto vacío, \`{}\`, y lo pasa al proveedor de tokens sin exigir que sea una cadena de texto. La colección de tokens interpreta ese objeto vacío como una consulta sin filtro y devuelve el primero de la lista; el proveedor autentica la petición como el propietario de ese token si aún no ha caducado. Con la sesión abierta, la ruta \`/rest/v0/users/me/authentication\_tokens\` entrega identificadores de sesión reutilizables.

Un objeto vacío donde se esperaba una cadena es el tipo de error que aparece cuando una capa valida y otra confía en que la primera validó. Aquí no hay inyección sofisticada ni cadena de exploits: hay un tipo de dato que viaja sin comprobar hasta una función que no estaba escrita para recibirlo. La consecuencia es que el atacante hereda los privilegios de la primera sesión viva que encuentre, y en una instalación con actividad esa primera sesión suele ser la de un administrador.

Lo que convierte el fallo en grave no es el salto de sesión, si no dónde ocurre. Ese panel tiene las llaves de todas las máquinas virtuales y de las copias de seguridad del entorno.

El [aviso oficial de Vates](https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/) documenta la cadena completa y los indicadores de compromiso de la campaña que la está explotando. El actor opera desde \`91.211.251.112:8001\`, una dirección que VirusTotal ya tenía marcada como centro de control de RedLine Stealer, y desde un servicio oculto en Tor. Que el mismo servidor haya servido antes para robar contraseñas dibuja un perfil de atacante oportunista con herramientas recicladas, no de grupo con recursos estatales.

## El rastro cuando se entra por el hipervisor

Una intrusión en un panel de virtualización es distinta a una intrusión en una web. El atacante no busca desfigurar nada: busca persistencia por debajo del sistema operativo invitado, donde los antivirus de las máquinas virtuales no llegan. Los indicadores publicados apuntan a una máquina virtual llamada \`pivot2\`, a configuraciones que desvían el puerto serie a un fichero del host y a ficheros con nombres \`/.ustar5\`, \`/.ustar6\` y \`/etc/cron.d/zz-ustar\`. También a una manipulación de \`/etc/ld.so.preload\`, la vía clásica para inyectar una biblioteca en todos los procesos del sistema.

Los comandos que Vates propone para revisar un host son cortos, se ejecutan en segundos y conviene lanzarlos antes de dar por buena una instalación, incluso si el panel nunca estuvo expuesto a internet:

```
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*
```

Encontrar la máquina \`pivot2\` o cualquiera de esos ficheros no es una sospecha, es una confirmación de que alguien ha estado dentro. El paso siguiente no es limpiar, es asumir que las credenciales del entorno están comprometidas y rotarlas todas: las de los usuarios de Xen Orchestra, las del proxy, las de las copias de seguridad y las de los buckets S3 que estén configurados.

La detección a nivel de red añade una capa que Xen Orchestra no ofrece por sí sola. Buscar en capturas de tráfico las cadenas \`authenticationToken=j:%7B%7D\` y \`authenticationToken=j:{}\` es la única forma directa de ver el intento, porque el uso de la cookie no deja identificador en el log de la aplicación. Un proxy inverso con esa regla configurada convierte un fallo invisible en una alerta, aunque conviene no fiarse del todo de ella: Vates advierte de que la regla se puede esquivar con otros formatos de codificación del mismo objeto.

Tres defensas, entonces: actualizar, cerrar la puerta y mirar el tráfico. La primera tapa el fallo, la segunda reduce el daño y la tercera sirve para saber si la respuesta llega tarde.

## Parchear no basta si el panel mira a internet

Los paquetes corregidos están disponibles en los dos canales. Xen Orchestra 6.9.1, en el canal estable, incluye xo-server 5.211.2; Xen Orchestra 6.10.0, en el canal latest, lleva xo-server 5.213.1. Quien no pueda actualizar ya tiene tres mitigaciones razonables: sacar la instancia de internet y meterla en una red de gestión dedicada, bloquear la dirección y el dominio del atacante para romper la cadena de mando, y prohibir el token vacío en el WAF o en el proxy inverso.

Ninguna de las tres resuelve el problema de fondo. Un panel de virtualización es infraestructura crítica: si se alcanza por internet, cualquier fallo de autenticación se convierte en un compromiso total sin que medien más pasos. La recomendación de Vates de no exponer Xen Orchestra no es una nota al pie, es la medida que habría dejado este ataque sin objetivo.

Hay además un factor de calendario. Este noviembre está siendo movido para XCP-ng: el mismo fabricante publicó el 3 de noviembre el aviso de [CVE-2026-98432, un fallo de memoria en el código IPv4 que afecta a XCP-ng 8.3](https://observatorioblockchain.com/ciberseguridad/cve-2026-98432-kernel-tcp-ubuntu-rhel-sin-parche/), y una semana después llega un salto de autenticación explotado. Quien administre estos entornos hará bien en tratar el par de avisos como una sola ventana de mantenimiento y no como dos sustos separados.

## El eslabón que nadie audita

La virtualización vive en un punto ciego de la seguridad cotidiana. Los equipos revisan el sistema operativo de las máquinas, las aplicaciones que corren dentro y las credenciales de los usuarios, mientras el hipervisor sigue ahí, con una interfaz web de la que dependen todos los demás, y rara vez entra en el inventario de activos expuestos. VSA-2026-062 no es un fallo exótico: es la demostración de que un objeto vacío en el sitio equivocado basta para saltarse una de las capas más sensibles de la infraestructura.

Mientras no haya CVE asignado ni análisis público del vector, la ventana de exposición depende de una sola cosa, y es la misma de siempre: cuánto tarda una actualización en llegar a la máquina que importa. Los avisos de Vates llevan fecha, versión y comando de comprobación. Lo que falta es la costumbre de ejecutarlos, como demostró el caso de [los NAS QNAP comprometidos por Plex2Shell](https://observatorioblockchain.com/ciberseguridad/qnap-plex2shell-nas-comprometidos-media-server/), donde el servidor de copias acabó siendo la puerta de entrada a toda la red.