Critical Xen Orchestra Auth Bypass Exploited to Hijack VMs

A critical authentication bypass in Xen Orchestra, tracked as VSA-2026-062, is being actively exploited. Attackers can log in as an existing user without credentials and may take over XCP-ng hosts, so update to a fixed release now.

What happened

BleepingComputer reported on November 10, 2026 that attackers are abusing the flaw in the wild. Xen Orchestra is a web-based management platform from the French company Vates. It manages XCP-ng environments, including virtual machines, hosts, and pools.

The bug is in how Xen Orchestra processes authentication cookies. An attacker sends the cookie authenticationToken=j:%7B%7D, which contains an empty JSON object ({}). The platform then retrieves an existing authentication token and logs the attacker in as its owner.

Once in, the attacker can fetch "reusable login token IDs" from the /rest/v0/users/me/authentication_tokens REST API endpoint. Those tokens can be used for further access.

Security researchers Filip Magic and Christoffer Olsen of TDC NET Security discovered the vulnerability.

Who is affected and which versions fix it

The flaw affects both Xen Orchestra and the Xen Orchestra Appliance (XOA). The attacker needs network access to the management interface. No credentials are required.

Vates fixed it in Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest). The patched xo-server packages are 5.211.2 and 5.213.1.

The two xo-server packages, 5.211.2 and 5.213.1, ship across these releases. The advisory lists them together, so we do not pair each package with one channel. If you run an older build, plan an update today and pick the release that matches the channel you follow.

How serious it is and whether it is exploited

Vates confirmed active exploitation. Its advisory warns: "An adversary can bypass authentication and perform actions with 'Admin' privilege. Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root."

That is why we rate it as an emergency for any management interface reachable from the internet or from a flat internal network. One cookie is enough, and the result is admin control of the hypervisors. A CVE identifier and CVSS score have not been assigned yet, so check the Vates advisory for updates.

Patch first, then reduce exposure

Follow these steps in order:

1. Update to Xen Orchestra 6.9.1 (stable) or 6.10.0 (latest). These include the patched xo-server packages 5.211.2 and 5.213.1.

2. If you cannot patch yet, restrict Xen Orchestra access to dedicated management networks. Also block the known malicious IP addresses listed below.

3. If you think you were compromised, rotate the passwords and secrets used by your virtualization environment.

A quick check of who can reach the web interface is worth doing even after patching. The management UI rarely needs to be reachable from user networks.

Check whether you were hit

Vates shared indicators of compromise (IOCs) from the attack campaign it observed:

• Attacker infrastructure: connections to 91.211.251.112:8001 or ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333

• Cookies: HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}

• VMs: a VM named pivot2, or VMs configured with hvm_serial: file

• Files: /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5, and /.ustar6

Run these on each XCP-ng host, as listed by Vates. They look for odd VM configurations, VMs using a file for the serial port, and the malicious files:

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*

The third command also lists /etc/ld.so.preload. Treat an unexpected /etc/ld.so.preload as suspicious and review it together with any .ustar files you find.

The next command is our own suggestion, not part of the Vates list. It shows live TCP connections to the attacker IP address from a host or XOA shell:

ss -tn | grep 91.211.251.112

It only catches connections that are open right now. It will not show traffic to the .onion address, and an empty result does not clear you.

Exploitation does not leave identifiers such as the crafted cookie in Xen Orchestra logs. Detection has to come from HTTP monitoring, for example a reverse proxy, WAF, or IDS that records cookie headers. Vates also says the IOCs match only this known campaign and may differ for other threat actors.

A simple triage order

1. Patch or isolate the Xen Orchestra server.

2. Run the three host commands on every pool member.

3. If you find pivot2, hvm_serial: file, any .ustar file, or an unexpected /etc/ld.so.preload, treat the host as compromised.

4. Rotate secrets, then review your HTTP monitoring data for the cookie values above.

What IT and security learners can take from this

This case shows why management planes are high-value targets. One parser mistake in a login path gave admin control over the hypervisors below it. Good habits help here: keep management interfaces on isolated networks, patch quickly, and monitor at the HTTP layer because application logs may stay silent. For a clear view of how intrusions unfold, read our guide on cyberattack stages and response. You can also browse our cybersecurity certification paths.

If you want to build skills in running virtualized and cloud infrastructure, the CompTIA Cloud+ CV0-004 voucher costs $224.99 and is delivered by email within 12 hours.

Sources

• Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers (BleepingComputer)