Vates security advisory

A vulnerability was discovered in Xen Orchestra that is part of the Xen Orchestra Appliance. We classify the impact as Critical . For details on how we assign severity levels, see our Severity Levels Explained page . This vulnerability is actively exploited by a threat actor operating from 91.211.251.112:8001 and ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333 (via Tor)

REST cookie parsing turns authenticationToken=j:%7B%7D into {} . REST authentication passes that object to the XO token provider without requiring a string. The token collection treats {} as an unfiltered lookup and returns its first token; the provider authenticates as that token's owner if it is unexpired. The authenticated /rest/v0/users/me/authentication_tokens route then returns reusable login token IDs.

An adversary can bypass authentication and perform actions with 'Admin' privilege. Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root .

xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest) : Affected.

Xen Orchestra Appliance: Affected.

The detection methods provided by Vates are based on the indicators of compromise (IoC) associated with the attack identified so far. These detection methods therefore only cover this specific campaign. Exploitation of the vulnerability by other threat actors using different TTPs and infrastructure cannot be ruled out. The absence of these IoCs alone is not sufficient to conclude that no compromise has occurred.

In the case of a successful exploitation, there is no log to detect unauthenticated access. However, the exploit can be detected by monitoring HTTP requests (tcpdump or Wireshark) using these patterns :

authenticationToken=j:%7B%7D

authenticationToken=j:{}

for pivot2 VM in running VMs.

for VM using hvm_serial: file parameter

for /etc/cron.d/zz-ustar2 , /etc/cron.d/zz-ustar , /.ustar5 , and /.ustar6 files

Security fixes are delivered to the latest channel and the stable channel.

Several mitigation options are available. Select the one best suited to the deployment context and stability requirements but it is strongly recommended to update as soon as possible.

Do not expose Xen Orchestra to the Internet

Put Xen Orchestra instance on a dedicated management network

Block the IP address and domain name where threat actor operating from to break the kill chain

Ongoing malicious activity cannot be ruled out. Immediate blocking of all traffic to and from the identified C2 infrastructure is strongly recommended.

Add a filter rule for ingress and egress traffic to block :

Block Tor traffic to prevent communication with ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion

Block the empty token in a WAF or a reverse proxy (be cautious with regex, the rule can be bypassed using other formats)

Add a rule to match these patterns :

authenticationToken=j:{}

authenticationToken=j:%7B%7D

Rotate all passwords and secrets in Vates VMS if Xen Orchestra has been compromised

Configuration exfiltration and credential harvesting cannot be ruled out. Rotate all passwords and secrets used by Vates VMS like proxy, backup, S3, root account, users account, etc.

As of 2026-11-10, Xen Orchestra version 6.10.0 and Xen Orchestra 6.9.1 has been updated and includes the fix for this issue. It is currently available on the latest channel and on stable channel.

List of packages fixing this issue:

xo-server : version 5.213.1 ( latest channel)

xo-server : version 5.211.2 ( stable channel)

Discovered by Filip Magic (@mad31k) and Christoffer Olsen from TDC NET Security