Xen Orchestra authentication bypass gives admin access and can lead to XCP-ng host takeover

What happened

On 10 November 2026, Vates published security advisory VSA-2026-062 about a critical authentication bypass in Xen Orchestra. Xen Orchestra is the web-based management interface for XCP-ng virtualization environments. No CVE ID or CVSS score has been assigned yet.

The flaw is in how the REST API handles the login cookie. A cookie with the value authenticationToken=j:%7B%7D is parsed into an empty object ({}). This object is passed to the token check without verifying that it is a string. The token lookup then returns the first stored token, and the request is authenticated as that token's owner, as long as the token has not expired. Through the endpoint /rest/v0/users/me/authentication_tokens, an attacker can then read reusable login token IDs.

According to Vates, an attacker can use this to perform actions with Admin privileges in Xen Orchestra without credentials. This can lead to arbitrary code execution on managed pools and a full takeover of XCP-ng hosts as root.

Vates states that the vulnerability is being actively exploited by a threat actor operating from 91.211.251.112:8001 and from a Tor address (see below). It is not known when the attacks started or whether the flaw was exploited before the fix was released. The flaw was discovered by Filip Magic and Christoffer Olsen of TDC NET Security.

Who is affected

• Xen Orchestra before 6.9.1 (stable channel) and before 6.10.0 (latest channel)
• the corresponding xo-server packages before 5.211.2 (stable) and 5.213.1 (latest)
• the Xen Orchestra Appliance (XOA)

The attacker needs network access to the Xen Orchestra web interface. Instances reachable from the internet are at the highest risk. XCP-ng hosts are at risk because Xen Orchestra manages them. If you do not run Xen Orchestra, this advisory does not affect you.

What to do now

1. Update Xen Orchestra. Install Xen Orchestra 6.9.1 on the stable channel or 6.10.0 on the latest channel. These include xo-server 5.211.2 (stable) or 5.213.1 (latest). Back up the Xen Orchestra configuration first. After the update, confirm that xo-server is running and that you can log in and see your pools.
2. Restrict access. Do not expose Xen Orchestra to the internet. Vates recommends placing it on a dedicated management network that only administrators can reach, for example through a VPN.
3. Block the attacker infrastructure. Vates recommends ingress and egress filter rules for 91.211.251.112 and blocking Tor traffic, so the hosts cannot reach ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. If you cannot update immediately, block the empty token in a WAF or reverse proxy in front of Xen Orchestra. Match the cookie patterns authenticationToken=j:{} and authenticationToken=j:%7B%7D.
5. Check for a compromise (see the next section). If you find signs of compromise, rotate all passwords and secrets used in your Xen Orchestra and XCP-ng environment, and investigate the affected hosts and VMs.

How to check whether you are affected

First, check your Xen Orchestra version in the web interface or on the appliance. If it is older than 6.9.1 (stable) or 6.10.0 (latest), the system is vulnerable.

Vates and the published reports list these indicators of compromise for the known attack campaign:

• HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}
• connections to 91.211.251.112:8001 or ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• a virtual machine named pivot2
• virtual machines configured with hvm_serial: file
• the files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6

On the XCP-ng hosts, run the checks recommended by Vates:

xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'

zgrep -- '-serial file:' /var/log/xensource.log*

ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

Also look for a VM named pivot2, for example with xe vm-list name-label=pivot2.

According to the reports, Xen Orchestra does not log the crafted cookie. You can only detect it through HTTP monitoring, for example in the access logs of a reverse proxy in front of Xen Orchestra. Check those logs and your firewall logs for the cookie patterns and the addresses above. Vates notes that these indicators belong to one known campaign. Other attackers may leave different traces, so finding none of them does not prove that a system is clean.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/hackers-exploit-critical-xen-orchestra.html