Xen Orchestra auth bypass VSA-2026-062 is being exploited to take over XCP-ng hosts

Vates, the French company behind the XCP-ng hypervisor, has published a critical advisory for Xen Orchestra, the web console used to manage XCP-ng and Xen pools. The flaw, VSA-2026-062, lets an attacker skip the login entirely, and Vates says a threat actor is already exploiting it. There is no CVE or CVSS score yet. Fixed builds shipped on 10 November.

What the bug does

According to the advisory, Xen Orchestra’s REST API parsed a specially crafted authenticationToken cookie into an empty object instead of a string. The token provider passed that object straight to a database lookup, which treated it as “no filter” and returned the first stored token. If that token had not expired, the request was authenticated as its owner. From there, a REST route that lists the user’s login tokens handed back reusable token IDs.

Vates rates the result as admin-level access to Xen Orchestra, which “can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root”. The fix in pull request #10748, merged on 10 November, rejects non-string and empty token IDs before any lookup.

Who should care

If you run XCP-ng in a homelab or on self-hosted GPU and inference machines, Xen Orchestra is probably how you manage it. The console holds the keys to every host it manages, plus backup remotes and pool secrets, so anyone who reaches its web port without a login reaches everything behind it.

Fixed versions

Vates lists every Xen Orchestra release before 6.9.2 (stable) and 6.10.1 (latest) as affected, along with the Xen Orchestra Appliance. The fixed packages are xo-server 5.211.2 (stable channel) and xo-server 5.213.1 (latest channel). If you built Xen Orchestra from source, Vates says to update to the latest master.

The Hacker News reported the fixed releases as 6.9.1 and 6.10.0. The advisory itself lists those earlier versions as affected and names 6.9.2 and 6.10.1 as fixed, so go by the vendor’s numbers.

Signs of compromise

Vates says a successful exploit leaves no log of the unauthenticated access, so it lists campaign indicators instead:

• HTTP requests whose cookie carries authenticationToken=j:{} or its URL-encoded form, visible in packet captures
• a running VM named pivot2, or VMs configured with hvm_serial: file
• files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6 on XCP-ng hosts (Vates’s check command also looks at /etc/ld.so.preload)

The advisory names 91.211.251.112 (port 8001) and a Tor onion service as the actor’s initial infrastructure, and lists seven more IP addresses to block in both directions. Vates warns that other attackers may use different infrastructure, so a clean check does not prove you were not hit.

What to do now

1. Update to Xen Orchestra 6.9.2 or 6.10.1, or the matching xo-server package, today.
2. Keep the console off the internet and on a dedicated management network.
3. Until you can patch, block the advisory’s IP list and Tor traffic, and add a WAF or reverse-proxy rule for the empty-token cookie. Vates cautions that such a rule can be bypassed with other encodings.
4. If you find any indicator, rotate every password and secret Xen Orchestra knows: proxies, backup remotes, root and pool secrets, user accounts, OTP secrets and mail settings. For a confirmed compromise, Vates recommends a full reinstall.

Vates credits Filip Magic and Christoffer Olsen of TDC NET Security with finding and reporting the flaw.