Vates, the company behind the Xen Orchestra management platform for XCP-ng virtualization hosts, says a critical authentication bypass in the product is being actively exploited. The flaw is tracked as VSA-2026-062 and has no CVE identifier or CVSS score yet. A remote attacker who can reach the management interface can log in as an administrator without credentials, and Vates says a compromised Xen Orchestra can lead to arbitrary code execution on managed pools and a full root takeover of XCP-ng nodes.
The mechanism, as Vates describes it: the REST API reads a cookie called authenticationToken, and a cookie whose value decodes to an empty JSON object (authenticationToken=j:%7B%7D) makes the token lookup return the first existing token, so the server authenticates the attacker as that token’s owner. The attacker can then list “reusable login token IDs” through /rest/v0/users/me/authentication_tokens. TDC NET Security researchers Filip Magic and Christoffer Olsen are credited with the find. The Hacker News reports it is unclear when the activity started or whether the flaw was exploited as a zero-day. THN also says VirusTotal flags one of the attacker IPs as a RedLine Stealer command-and-control server; we did not read that page.
How to check if you’re affected
Affected versions, per Vates’ advisory (read at the time of writing), are Xen Orchestra before 6.9.2 on the stable channel and before 6.10.1 on the latest channel, plus the Xen Orchestra Appliance (XOA). The fix ships as xo-server 5.211.2 (stable) and 5.213.1 (latest); if you installed from source, Vates says to update to the latest master. BleepingComputer and The Hacker News both give the fixed releases as 6.9.1 and 6.10.0, which differs from the advisory; use the vendor’s numbers (our suggestion: if in doubt, update to the newest release).
Vates warns that exploitation leaves no log entry, so detection depends on HTTP monitoring (for example tcpdump or Wireshark) for authenticationToken=j:%7B%7D or authenticationToken=j:{}. Other indicators Vates lists for this campaign:
- A running VM named
pivot2, and VMs configured with thehvm_serial: fileparameter. On XCP-ng hosts, Vates gives these checks:xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'andzgrep -- '-serial file:' /var/log/xensource.log*. - Files
/etc/cron.d/zz-ustar,/etc/cron.d/zz-ustar2,/.ustar5and/.ustar6; Vates’ check isls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*. - Network connections to 91.211.251[.]112:8001 and to the onion service
ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid[.]onion:3333. Vates’ block list also names 193.148[.]56.72, 37.221[.]208.216, 45.66[.]35.11, 64.65[.]0.120, 64.65[.]62.160, 89.47[.]51.90 and 92.60[.]37.247.
Vates stresses these indicators only cover the attack it has seen, and that their absence does not prove you are clean. If you cannot patch immediately, it advises not exposing Xen Orchestra to the internet, keeping it on a dedicated management network, blocking the addresses above and Tor traffic, and blocking the empty-token cookie in a WAF or reverse proxy (it warns a regex rule can be bypassed with other formats). If you find signs of compromise, Vates says to rotate every password and secret used by the platform (proxy, backup remotes such as NFS, S3, Azure and SMB, the root account and pool secret, user accounts, OTP secrets and mail-server passwords) and recommends a full reinstall, because cleanup alone cannot guarantee backdoors are gone.