CriticalVulnerabilityActive

Xen Orchestra auth bypass (VSA-2026-062) exploited, update now

Vates says a critical Xen Orchestra authentication bypass, VSA-2026-062, is exploited; update to the fixed release and restrict access.

Published
Fixed in
Xen Orchestra 6.9.2 (stable) and 6.10.1 (latest) per Vates; xo-server 5.211.2 (stable) and 5.213.1 (latest)
Exploitation
Yes, Vates states the flaw is actively exploited by a threat actor and published indicators of compromise

What happened

Vates published advisory VSA-2026-062, “Empty-object login token”, on 2026-11-10. It rates the flaw Critical and says it is actively exploited by a threat actor. The advisory lists the CVSS 4.0 score as “Not available yet” (Vates advisory). BleepingComputer reports that neither a CVE identifier nor a CVSS score has been assigned yet. The Hacker News reports that the flaw does not yet have a CVE identifier.

According to Vates, REST cookie parsing turns authenticationToken=j:%7B%7D into an empty object {}. The token provider accepts that object without requiring a string. The token collection treats {} as an unfiltered lookup and returns its first token, and the provider then authenticates the request as that token’s owner if the token is unexpired. The authenticated /rest/v0/users/me/authentication_tokens route then returns reusable login token IDs (Vates advisory).

Vates says an attacker can act with Admin privilege, and that a compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root. BleepingComputer describes Xen Orchestra as a web-based management platform from Vates for XCP-ng environments, and says the attack requires network access to the management interface.

Vates names the initial attacker infrastructure as 91.211.251.112:8001 and an onion address on port 3333 reached via Tor. The Hacker News adds that the IP address has been flagged as a RedLine Stealer command-and-control server on VirusTotal. It also says it is unclear when the activity started and whether the flaw was exploited as a zero-day. Neither point is confirmed in the Vates advisory.

Filip Magic and Christoffer Olsen of TDC NET Security are credited with discovering and reporting the flaw.

Am I affected?

Per the Vates advisory, Xen Orchestra before 6.9.2 (stable) and before 6.10.1 (latest) is affected, and so is the Xen Orchestra Appliance (XOA).

The outlets differ on version numbers. BleepingComputer and The Hacker News report the fixes as Xen Orchestra 6.9.1 and 6.10.0. The Vates advisory lists 6.9.2 and 6.10.1 as the fixed versions as of 2026-11-10. This advisory follows the vendor page. The xo-server package versions (5.211.2 stable, 5.213.1 latest) are the same in all three sources.

Vates lists these indicators of a compromise by this known campaign:

  • HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}
  • A running VM named pivot2
  • VMs configured with the hvm_serial: file parameter
  • Files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6

Vates warns that successful exploitation leaves no log entry, so the cookie pattern can only be detected by monitoring HTTP traffic (tcpdump or Wireshark). The indicators cover only this campaign, other actors may use different infrastructure, and the absence of these indicators does not prove there was no compromise.

What to do now

  1. Update Xen Orchestra to the fixed release on your channel: 6.9.2 (stable) or 6.10.1 (latest), with xo-server 5.211.2 or 5.213.1. If you installed from source, Vates recommends updating to the latest master.
  2. If you cannot patch immediately, do not expose Xen Orchestra to the internet and place it on a dedicated management network (Vates advisory).
  3. Block the empty token in a WAF or reverse proxy, matching authenticationToken=j:{} and authenticationToken=j:%7B%7D. Vates cautions that regex rules can be bypassed using other formats.
  4. Block ingress and egress traffic to the addresses Vates lists: 91.211.251.112, 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. Also block Tor traffic to the onion address.
  5. Check for compromise. Search running VMs for pivot2, and on XCP-ng hosts run the commands Vates provides:
    • 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*
  6. If you suspect compromise, rotate all passwords and secrets used by Vates VMS: proxy, backup remotes (NFS, S3, Azure, SMB), root account, pool secret, user accounts, OTP secrets and mail server config passwords. Vates says configuration exfiltration and credential harvesting cannot be ruled out. For a confirmed compromise it recommends a full reinstallation, because cleanup alone cannot guarantee removal of all backdoors.

Sources