VSA-2026-062: Xen Orchestra auth bypass is being exploited

Call: Patch now. Vates rates VSA-2026-062 Critical and says a threat actor is already exploiting it. One crafted cookie gets an attacker into Xen Orchestra as an admin, and from there they get root on your XCP-ng hosts. No CVE or CVSS score yet.

Update, Nov 11: Updating doesn’t finish the job. In a second advisory, VSA-2026-063, Vates says the same attacker used the Admin access from this bug to import crafted VMs that compromise XCP-ng hosts. That flaw isn’t fixed in any release yet, 6.9.2 and 6.10.1 included. An unprivileged user with import rights can abuse it too. Until Vates ships a fix, allow VM imports for Admin users only, and disable any user who holds vm.import, sr/import:vm, network/action:create or network/action:update. (Vates VSA-2026-063 (opens in a new tab))

What breaks: Xen Orchestra’s REST cookie parsing turns authenticationToken=j:%7B%7D into an empty object, {}. The token lookup treats that as “match anything”, returns the first unexpired token, and logs the attacker in as that token’s owner. Then /rest/v0/users/me/authentication_tokens hands over reusable login tokens. Vates says the result is “arbitrary code execution on managed pools and a full XCP-ng node takeover as root.”

The bad part: a successful login with the forged cookie leaves nothing in Xen Orchestra’s logs. Only HTTP monitoring sees it.

Who’s hit: Xen Orchestra before 6.9.2 (stable) and 6.10.1 (latest), and the Xen Orchestra Appliance. If you built XO from source, update to the latest master. Exposure is worst where the XO web UI is reachable from the internet or a flat network.

Fix: Xen Orchestra 6.9.2 (stable, xo-server 5.211.2) or 6.10.1 (latest, xo-server 5.213.1). (BleepingComputer printed 6.9.1 and 6.10.0; the Vates advisory says those are still affected.)

Workaround: Until you can update:

Take XO off the internet and put it on a management network.
Block the advisory’s C2 addresses in and out (91.211.251.112 plus seven more listed), and block Tor.
Add a WAF or reverse-proxy rule for authenticationToken=j:{} and j:%7B%7D. Vates warns that a regex can be bypassed with other encodings, so treat this as a speed bump.

Check whether you were hit:

Look for a VM named pivot2.
On each host, run xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file' and zgrep -- '-serial file:' /var/log/xensource.log*.
Check for /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5, /.ustar6 and a modified /etc/ld.so.preload.

These indicators cover only the campaign Vates has seen, so a clean result isn’t proof. If you find anything, rotate every secret XO holds: backup remotes, pool secret, root, users, OTP, mail. Vates recommends a full reinstall over cleanup.

Sources: Vates VSA-2026-062 (opens in a new tab), Vates VSA-2026-063 (opens in a new tab), BleepingComputer (opens in a new tab).

VSA-2026-062: Xen Orchestra auth bypass is being exploited

Sources

More from November 2026 patch cycle