Xen Orchestra: an exploited authentication bypass gives attackers admin rights over XCP-ng virtualisation

Top-Secured cyber watch: independent analysis based on the sources listed below. Top-Secured is not affiliated with the companies mentioned and will never ask you for your bank details or passwords.

Vates has fixed a critical flaw in Xen Orchestra, the web console used to manage XCP-ng hosts, and says it is already being exploited. A crafted cookie lets an attacker log in as an existing user, usually an administrator, without a password. Versions 6.9.2 and 6.10.1 fix it; exposed consoles must also be checked for compromise.

What happened

On 10 November 2026, Vates, the French company behind Xen Orchestra and XCP-ng, published advisory VSA-2026-062, rated critical, and states that the flaw is being actively exploited. No CVE identifier or CVSS score had been assigned when it was published. Fixed versions came out the same day.

The bug lies in the authentication of the REST API. A cookie whose token is a crafted empty object, instead of a text string, reaches the token lookup unchecked. The lookup then returns the first valid token stored by Xen Orchestra, and the request is treated as coming from that token’s owner. From there, the attacker can list reusable login tokens and act with administrator rights. The fix, merged on GitHub, rejects any token that is not a non-empty string.

Who is at risk

All Xen Orchestra installations older than 6.9.2 (stable channel) and 6.10.1 (latest channel), whether the XOA appliance or a build from source. According to Vates, taking over the console can lead to code execution on the managed pools and to root access on XCP-ng hosts. Consoles reachable from the internet are the first in line.

What to do now

1. Update: XOA to 6.9.2 (stable) or 6.10.1 (latest), i.e. xo-server 5.211.2 or 5.213.1; installations from source to the latest master commit, then rebuild.
2. Take the console off the internet: a dedicated management network or a VPN only.
3. Filter: block the IP addresses and the Tor address listed in the advisory, and, on your reverse proxy, requests whose authenticationToken cookie starts with j:. Vates warns that other encodings can get past such a rule.
4. Look for traces: a successful attack leaves no entry in the authentication log. Look for a VM named pivot2, then on each XCP-ng host run xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', zgrep -- '-serial file:' /var/log/xensource.log* and ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*.
5. If compromised: change every secret known to the platform (root accounts, pool secret, backup remotes, proxies, users, OTP secrets, mail server) and, as Vates recommends, reinstall rather than clean up.

Our take

A hypervisor console holds the keys to every virtual machine: it is the most sensitive server in the company and has no business on the internet. Patching is not enough this time: since the attack leaves no login trace, only a check of the hosts tells you whether someone already came in.

Sources

• Vates — VSA-2026-062: Empty-object login token
• GitHub (vatesfr/xen-orchestra) — fix(xo-server): validate authentication token IDs, PR #10748
• The Hacker News — Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access

How we choose, verify and write our analyses →