Vates has disclosed VSA-2026-062, a critical authentication bypass in Xen Orchestra (XO) and the Xen Orchestra Appliance (XOA). Vates says it is already being exploited. One crafted cookie gives an unauthenticated attacker Admin rights in XO. Because XO manages XCP-ng pools, that means code execution on managed pools and full takeover of XCP-ng hosts as root. The advisory was published on November 10, 2026. No CVE ID or CVSS score had been assigned at the time of writing.

What Happened

Vates reports active exploitation by a threat actor working from a specific IP address and a Tor domain. The flaw was found and reported by Filip Magic and Christoffer Olsen of TDC NET Security. Vates released fixes the same day it published the advisory.

The vendor is clear that attacks leave no trace in XO’s own logs: “there is no log to detect unauthenticated access.” If your XO instance was reachable by untrusted networks before you patched, assume it may have been accessed.

Technical Details

The bug is in how XO’s REST layer parses cookies. Vates’ advisory, titled “Empty-object login token”, describes the chain:

  1. XO’s cookie parser supports Express-style JSON cookies, where values prefixed with j: are decoded as JSON. A request that sends authenticationToken=j:%7B%7D (URL-encoded j:{}) produces an empty object {} where a token string was expected.
  2. The REST layer passes that object straight to the token provider. The provider treats {} as an unfiltered lookup and returns the first unexpired token in the store. The caller is then authenticated as that token’s owner, which is usually an administrator.
  3. A second route then lets the attacker list reusable login token IDs. This gives them durable access that survives beyond the first request.

It is a type-confusion bug: the code assumed a string, and a JSON-capable cookie parser handed it an object. Once in, the attacker holds XO Admin rights. That covers creating and modifying VMs, attaching disks, running jobs against pools, and reaching hosts with root-equivalent control. For an attacker, the hypervisor management plane may be the most valuable target in the building. Ransomware crews have spent the past two years going after ESXi and vCenter for exactly this reason, and XO is the XCP-ng equivalent.

Affected and Fixed Versions

The initial fixes are:

  • Stable channel: Xen Orchestra 6.9.1 / xo-server 5.211.2
  • Latest channel: Xen Orchestra 6.10.0 / xo-server 5.213.1

The advisory’s affected-versions section lists XO releases before 6.9.2 (stable) and 6.10.1 (latest) as affected. That suggests the affected range was widened after the first fix shipped. Until Vates clarifies, move to the newest build on your channel rather than stopping at 6.9.1 or 6.10.0. XOA users should update through the appliance updater. Anyone running XO built from source should pull and rebuild from current master.

Impact

  • Who’s exposed: any XO/XOA instance whose web interface is reachable from a network the attacker can reach. Internet-exposed instances are at highest risk, but a foothold on a flat internal network is enough.
  • Blast radius: every pool and host the XO instance manages. XO often holds credentials for all XCP-ng pools in an environment, plus backup targets (remotes), so one compromised XO can mean the whole virtualization estate and its backups.
  • Detection: XO does not log the bypass, so normal audit review will not find it.

Mitigation

  1. Patch now to the latest release on your channel (at least 6.9.2 stable or 6.10.1 latest, per the affected-versions line).
  2. Remove internet exposure. Put XO on a dedicated management network or VLAN. Allow access only via VPN or a bastion, and restrict it with firewall allowlists.
  3. Hunt in HTTP traffic. XO’s logs are blind to this, so check your reverse proxy, load balancer, or WAF logs for a Cookie header containing authenticationToken=j:%7B%7D or authenticationToken=j:{}. More generally, look for any authenticationToken value starting with j:. Add a WAF or proxy rule that drops such requests.
  4. Block the attacker infrastructure Vates published in the advisory (the IP and Tor domain).
  5. If exposure is suspected: revoke all XO authentication tokens, rotate XO user passwords and the XCP-ng host and pool credentials stored in XO, and rotate credentials for backup remotes. Then review pools for unexpected VMs, snapshots, VDI exports, scheduled jobs, new XO users, and changes to SSH keys or /etc on XCP-ng hosts.

References