Vates has confirmed that a critical authentication bypass in Xen Orchestra is being used in live attacks, and that a compromised management console can hand an attacker root on managed XCP-ng hosts.
What happened
Xen Orchestra is the web management layer for XCP-ng, the open-source Xen fork used to run virtual machines in a lot of small hosting and internal virtualisation estates. Vates published advisory VSA-2026-062 on 10 November 2026 and rated it Critical.
The flaw is in how the REST API turns a cookie into an authentication token. Send 'authenticationToken=j:%7B%7D', which decodes to an empty JSON object, and the token lookup treats that empty object as an unfiltered query and returns the first token it holds. If that token has not expired, the request is authenticated as its owner. The '/rest/v0/users/me/authentication_tokens' route then returns reusable login token IDs so the access can be extended.
No credentials are required. No CVE identifier has been assigned and no CVSS score has been published yet, so the advisory ID is what you track.
Who is affected
Only the console is vulnerable, not XCP-ng itself. The danger is what the console can do once someone else holds admin.
- Xen Orchestra before 6.9.2 on the stable channel and before 6.10.1 on the latest channel
- Xen Orchestra Appliance at any build older than those versions
- Any deployment whose console is reachable from the internet, a flat office network, or a shared management VLAN
What to do now
Update to Xen Orchestra 6.9.2 or 6.10.1 (xo-server 5.211.2 on stable, 5.213.1 on latest) now, then hunt for the published IOCs on the hosts before you trust anything the console reports.
- Move the console to a dedicated management network and close all inbound internet access to it.
- Block the infrastructure Vates published: 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, plus Tor egress.
- Search for a VM named pivot2, VMs carrying the hvm_serial: file platform parameter, and the files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6.
- A successful bypass leaves no log entry, so capture HTTP traffic and match 'authenticationToken=j:%7B%7D' or 'authenticationToken=j:{}' in request headers.
- If any indicator is present, rotate every secret in the stack (root, pool secret, user accounts, OTP secrets, backup remote credentials) and rebuild. Vates states that cleanup alone cannot guarantee removal of the backdoors.
What this means for South African businesses
Few SA SMEs run Xen Orchestra themselves, but the MSPs and hosting providers they rent virtual machines from frequently do, and a takeover there reaches every tenant in the pool. Where a provider exposes the console for convenience, one crafted cookie separates a management UI from root on the hypervisor. My read: the exposure is narrow but the blast radius is total, so any XCP-ng console reachable from the internet should be treated as already compromised until it is patched and checked. Not sure whether a console you rely on is exposed? Our IT Health Assessment checks this exact class of management-plane exposure.
Source
Vates security advisory VSA-2026-062: VSA-2026-062: Empty-object login token.