Xen Orchestra Auth Bypass VSA-2026-062 Exploited: An Empty-JSON Cookie Logs Attackers In as Admin and Hands Over XCP-ng Hosts as Root

Cyber · 2026-11-11 · By H.A

Vates warns that attackers are exploiting a critical Xen Orchestra authentication bypass that leaves no trace in application logs, and urges an immediate update to 6.9.1 or 6.10.0 plus hunting for the published indicators.

Vates, the company behind the XCP-ng virtualization platform, has warned that attackers are actively exploiting a critical authentication bypass in Xen Orchestra, the web-based management console used to run XCP-ng and XenServer pools. A single crafted cookie lets an unauthenticated attacker act as an administrator. From there, attackers can run code on managed pools and take over XCP-ng hosts as root.

The flaw is tracked as VSA-2026-062 and was disclosed on 10 November 2026. No CVE identifier or CVSS score had been assigned at the time of disclosure.

What Happened

Vates says it has confirmed attacks against exposed Xen Orchestra instances. It is not clear when exploitation started or whether the flaw was used as a zero-day before the fix shipped. Vates also warns that the attack leaves no identifiers in Xen Orchestra's own logs, so victims may not be able to tell from the application alone whether they were hit.

The vulnerability was found by security researchers Filip Magic and Christoffer Olsen of TDC NET Security.

Technical Details

According to Vates, the bug lies in how Xen Orchestra processes authentication tokens in REST API requests. An attacker sends a cookie named authenticationToken whose value is an empty JSON object. Instead of rejecting it, the server looks up an existing authentication token and logs the attacker in as that token's owner, without any credentials.

Once inside, the attacker can do the following:

• list reusable authentication token IDs through the REST endpoint /rest/v0/users/me/authentication_tokens
• perform any action with Admin privileges in Xen Orchestra
• run arbitrary code on the pools Xen Orchestra manages, and take full root control of XCP-ng nodes

Xen Orchestra holds credentials for every host and pool it manages, so compromising it effectively hands over the whole virtualization estate. That includes every VM, storage repository and backup job.

Indicators of Compromise

Vates shared indicators from the campaign it observed. It stresses that other attackers may use different infrastructure and tooling.

• HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}
• connections to attacker infrastructure at 91.211.251[.]112:8001 and a Tor onion service on port 3333
• a virtual machine named pivot2
• VMs configured with hvm_serial: file
• the files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6 on hosts

Vates suggests running these read-only checks on XCP-ng hosts:

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*

Any VM named pivot2, unexpected serial-to-file configuration, an unexplained /etc/ld.so.preload, or the zz-ustar cron files should be treated as signs of compromise.

Who Is Affected

Both the packaged Xen Orchestra Appliance (XOA) and Xen Orchestra installations built from source are affected. The highest risk is to instances reachable from the internet or from large, flat internal networks. Managed service providers and hosting companies that run XCP-ng for customers face extra exposure, because one console often manages many tenants.

Patch Status

Vates has released fixed versions:

• Xen Orchestra 6.9.1 (stable channel)
• Xen Orchestra 6.10.0 (latest channel)
• xo-server 5.211.2 and 5.213.1 for the corresponding package lines

XOA users can update through the appliance's built-in updater. Installations built from source should be rebuilt from the patched release.

What To Do Now

1. Update immediately to 6.9.1 or 6.10.0 (or the matching xo-server version).
2. Take Xen Orchestra off the internet. Put it on a dedicated management network or behind a VPN, and block the known attacker IP address at the perimeter.
3. Inspect HTTP traffic. Application logs will not show this attack, so check reverse-proxy, WAF or network logs for the empty-object cookie pattern.
4. Hunt on every XCP-ng host with the commands above, and review the VM list for machines nobody recognises.
5. If you find indicators, treat the whole pool as compromised. Rotate every password, API token and secret used by the virtualization environment, including Xen Orchestra user tokens, host root passwords and backup or storage credentials. Bring in incident response before rebuilding.

Why It Matters

Virtualization management planes are among the most valuable targets on a network. One compromised console can stop, copy, encrypt or delete every workload at once. Just days ago, a destructive attack wiped a hosting provider's cloud through its management plane, which shows how much damage this level of access allows.

An authentication bypass that needs only a cookie, leaves no application log trail and is already being exploited is about as urgent as a patch gets. Organisations running XCP-ng should patch, restrict network access and hunt for compromise on the same day.