Xen Orchestra Hosting Risk: What to Ask Your Host

On 10 November 2026, Vates VMS warned that Xen Orchestra, the web console for XCP-ng and Xen, is under active attack via VSA-2026-062, an authentication bypass with no CVE in that reporting. The Xen Orchestra hosting risk is one public management page that can put every guest on that pool within an attacker's reach.

Why does a Xen Orchestra flaw put ordinary websites at risk?

Xen Orchestra is the web console French vendor Vates VMS ships for XCP-ng and Xen hypervisor pools. From that console an administrator starts and stops virtual machines, attaches disks, changes networking, takes snapshots and runs actions across the pool.

Vates says a successful attacker can take arbitrary actions with Admin privileges, run code on managed pools and take an XCP-ng node over as root. Site files, the database and mail live on that node. The alert names no victim count and no threat group.

A compromised console can reach several sites even when each site has its own control panel. Website multi-factor authentication does not see this cookie path. In cleanup, you audit the CMS while the break-in sits on a panel only the host can open.

If you rent a VPS on XCP-ng, Xen Orchestra will not show up in WordPress or Joomla. You still inherit what that console can do to the virtual disk. It is the same split as another exposed hosting control panel: the host has the panel, you have the sites.

What is Xen Orchestra VSA-2026-062?

VSA-2026-062 is Vates’ tracking ID for an authentication bypass in the Xen Orchestra REST login path. The 10 November 2026 reporting gave no CVE. Ravie Lakshman’s Hacker News story that day carried the vendor alert.

Vates says exploitation is already underway. When it started, and whether the bug was used before the alert, is unknown. Filip Magic (@mad31k) and Christoffer Olsen of TDC NET Security found the flaw and reported it.

In the alert, REST cookie parsing turns authenticationToken=j:%7B%7D into an empty object, {}, instead of a string. The literal authenticationToken=j:{} does the same. The token provider accepts that object without requiring a string.

The token collection treats that empty object as an unfiltered lookup and returns its first token. If the token is unexpired, the requester is authenticated as its owner. The route /rest/v0/users/me/authentication_tokens then returns reusable login token IDs.

The alert says the flaw permits actions with Admin privileges, plus code execution on managed pools and root on XCP-ng nodes. This article will not reproduce a working request. Search logs for those two cookie strings, and copy network indicators from the Vates alert.

The alert names the builds that close the bug. Read the running Xen Orchestra and xo-server versions and compare them with those builds before you call the console safe.

Can a hacked Xen Orchestra take over the sites on an XCP-ng pool?

Yes. Vates describes Admin actions on the console, code execution on managed pools and a full XCP-ng node takeover as root. Root on the node controls the hypervisor that owns the virtual disks. That is separate from a WordPress or Joomla admin login.

Guest isolation is then a setting the attacker controls. Disks can be copied, snapshots exported and guest networking changed. A new VM can join the pool, with console access attached to a machine you thought was private.

Vates published a command-and-control IP and port, plus a Tor hidden-service address and port. VirusTotal has flagged that IP as RedLine Stealer infrastructure. The host should block it. The flag does not prove RedLine was installed on these consoles.

Search for HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}. Search for a running VM named pivot2, and for VMs whose hvm_serial parameter is set to file.

Search for /etc/cron.d/zz-ustar2, /etc/cron.d/zz-ustar, /.ustar5 and /.ustar6. An IP firewall does not drop a Tor onion address on its own. That needs a proxy, a DNS filter, or a ban on Tor from the host.

Keep proxy logs, Xen Orchestra logs and VM records before anyone deletes pivot2 and calls the pool clean. A missing name later is a weak sign. VMs get renamed and cron files get removed.

Which Xen Orchestra and xo-server versions close the flaw?

Vates fixed the bypass in Xen Orchestra 6.9.1 and 6.10.0 for the stable and latest channels, and in xo-server 5.211.2 and 5.213.1. Install one of those Orchestra builds with one of those xo-server packages. The alert lists both channels and both builds without pairing each number to one channel.

Compare the running version with the fixed builds. A note that the install is recent is not a version check.

Vates’ first mitigation is to keep Xen Orchestra off the internet. If it must stay up during patching, block the empty token at a WAF or reverse proxy. Reject authenticationToken=j:%7B%7D and authenticationToken=j:{}.

Keep full authentication cookies out of logs, because they are live credentials. If indicators appear, Vates says to block the malicious IP and the Tor domain and to rotate passwords and secrets in your Xen Orchestra environment.

If you run the console, take it off the public internet and patch both packages. If a host runs it for your VPS, you cannot patch it from the site.

Ask in writing and set a deadline. You hit the same limit when only the host can patch the layer under the site.

How do you check the Xen Orchestra hosting risk on a VPS?

Start on the guest you can log into. On many Linux VPS images, systemd-detect-virt prints xen when the machine runs under Xen or XCP-ng, and /sys/hypervisor is a second hint. Neither result proves the pool is managed by Xen Orchestra. A Xen guest can exist without that console.

You will not see the console version in wp-admin. If you administer Xen Orchestra, read the version in its interface and the xo-server version on the management host. You want Xen Orchestra 6.9.1 or 6.10.0, and xo-server 5.211.2 or 5.213.1.

If a provider owns the console, those strings are theirs to read and theirs to patch. WordPress and Joomla are not the buggy package. Their databases and uploads still live on disks that an Admin session on that console can read.

What should you ask your host about an exposed XCP-ng console?

Ask whether XCP-ng or Xen Orchestra is in the path of your sites, whether the console is on the public internet, and whether it is on 6.9.1 or 6.10.0 with xo-server 5.211.2 or 5.213.1. Those three answers tell you whether this advisory applies.

A host that cannot name the hypervisor console has not checked. Put the questions in one note:

• Do any of my virtual machines run on XCP-ng or a Xen pool managed by Xen Orchestra?
• Is Xen Orchestra reachable from the public internet, or only from a management network?
• Which Xen Orchestra and xo-server versions are installed, and on what date?
• Did anyone search logs for authenticationToken=j:%7B%7D and authenticationToken=j:{}?
• Was there a VM named pivot2, a VM with hvm_serial set to file, or the files /etc/cron.d/zz-ustar2, /etc/cron.d/zz-ustar, /.ustar5 or /.ustar6?
• If an indicator is present, were passwords and secrets in the Xen Orchestra environment rotated, and were my guest disks or snapshots accessed?

Ask for the version string and the install date, not a line that says the platform is secure. If they will not show that the console is off the internet, treat it as reachable until a firewall rule or a private address is in front of you.

The bypass needs no account, so one request from the internet is enough while the console is public. Visitor traffic on the website does not change that. A clean CMS scan does not clear the hypervisor. The FAQ below says why.

What should you change on the websites if the console looks dirty?

If the host confirms the indicators, or will not rule them out, treat passwords and keys on those virtual machines as exposed. That set includes WordPress and Joomla admin passwords, database credentials, API keys, FTP and SFTP logins, SMTP credentials, and payment or backup keys on disk.

1. Take the console off the internet and install Xen Orchestra 6.9.1 or 6.10.0 with xo-server 5.211.2 or 5.213.1 before new passwords count as safe.
2. Keep logs, VM configs and the ustar files. Deleting pivot2 first throws away evidence.
3. Treat root on the XCP-ng host as a possible guest compromise. Rebuilding from known-good media may be the real fix.
4. On each site, check new admins, unexpected server-side files, changed core and plugins, odd tasks and database users.
5. Rotate website secrets only after the console is patched and offline. New passwords on an exposed node stay readable.
6. Restore from backups that predate suspected access, then update again. A backup from an owned node can carry the implants.

Still scan the CMS for webshells and rogue admins. That scan cannot clear the hypervisor.

A website firewall watches requests to the site. This bug is in the console above it. Use antivirus website protection while the host works through the pool.

If the host is slow and the sites take payments or orders, copy files and the database somewhere that pool cannot reach, and be ready to move them. You cannot patch Xen Orchestra from wp-admin. You choose how long a public, unpatched console remains an acceptable risk for the sites.

FAQ

Is there a CVE number for the Xen Orchestra authentication bypass?

Not in the 10 November 2026 reporting. Vates tracks the bug as VSA-2026-062 and says it is being exploited. Waiting for a CVE number does not change the patch decision.

Which Xen Orchestra and xo-server versions include the fix?

Xen Orchestra 6.9.1 and 6.10.0 for the stable and latest channels, plus xo-server 5.211.2 and 5.213.1. The alert does not pair each Orchestra build with one channel. Compare the running version with that list.

Should Xen Orchestra be reachable from the public internet?

Vates says no. Keeping the console off the internet is the first mitigation. If it must stay up briefly, block authenticationToken=j:%7B%7D and authenticationToken=j:{} at a WAF or reverse proxy, and limit the listener to a management network.

What host artefacts did Vates say to look for?

Requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}, a VM named pivot2, VMs with hvm_serial set to file, and the files /etc/cron.d/zz-ustar2, /etc/cron.d/zz-ustar, /.ustar5 and /.ustar6. Files removed after the fact are not proof of a clean host.

If my host was exposed, which website passwords should I change?

After the console is patched and off the internet, rotate CMS admin passwords, database credentials, API keys, FTP and SFTP logins, mail credentials and backup secrets from those VMs. If indicators were found, Vates also says to rotate passwords and secrets in the Xen Orchestra environment.

Does a clean CMS malware scan prove the server was not taken over?

No. The scanner sees guest files: themes, plugins, core checks and obvious webshells. Root on the XCP-ng node can read disks and export snapshots without leaving a file that scan understands. Use the scan to find webshells and new admins. Judge the pool from the host's version, public exposure and the Vates artefacts.

If the host’s answers are thin and the sites already show new admins or strange files, cleanup has to cover the guest and the chance someone else could read the disk. SiteGuarding can help with malware removal and website protection while you press the provider on the console.