Xen Orchestra Auth Bypass Is Actively Exploited, Vates Says

Vates has warned that a critical authentication bypass in Xen Orchestra is being actively exploited and can give an attacker administrator rights over the management console. In advisory VSA-2026-062, published on 10 November 2026, the French company behind the Xen Orchestra web console and the XCP-ng hypervisor said the flaw affects both Xen Orchestra and the Xen Orchestra Appliance. “This vulnerability is actively exploited by a threat actor,” Vates wrote. It has assigned the issue a Critical severity rating. No CVE identifier has been issued, and no numeric CVSS score is available yet.

Administrators should treat this as an urgent patch-and-check problem, not a routine update. Vates says an attacker who bypasses authentication can act with Admin privilege, and that a compromised Xen Orchestra instance “can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root.” The company has shipped fixes and tells operators to keep the console off the public internet, on a dedicated management network. Installing the new packages does not, by itself, clean a system that has already been abused.

In brief

• Vates says a critical Xen Orchestra authentication bypass, tracked as VSA-2026-062, is being actively exploited and can lead to Admin access, then code execution on managed pools and a root takeover of XCP-ng hosts.
• Fixes are in Xen Orchestra 6.9.1 on the stable channel, with xo-server 5.211.2, and 6.10.0 on the latest channel, with xo-server 5.213.1. Update now, and keep Xen Orchestra off the public internet.
• The indicators Vates has published cover only the campaign it has identified. Their absence is not proof a system is clean, and a patch does not undo a compromise.

Xen Orchestra treated a malformed login token as a valid session

In plain terms, the flaw is in how Xen Orchestra handled a malformed login token. Vates says an empty object was accepted in place of a proper token identifier. The token lookup then ran without a real filter, selected the first token it found, and authenticated as that token’s owner if the token had not expired. The result is an authentication bypass, not a guessable password.

The official fix, merged on 10 November 2026 at 08:29 Europe/London, is described in a GitHub commit as validating authentication token IDs (pull request 10748). That is the change administrators should obtain by updating, rather than by trying to reconstruct the broken request themselves. The advisory credits Filip Magic and Christoffer Olsen of TDC NET Security with discovering the issue.

Fixes are out, and they are not a substitute for a clean system

As of 10 November 2026, Vates says the fix is available in Xen Orchestra 6.9.1 on the stable channel, which includes xo-server 5.211.2, and in Xen Orchestra 6.10.0 on the latest channel, which includes xo-server 5.213.1. Both Xen Orchestra and the Xen Orchestra Appliance are listed as affected, so appliance users need the updated build too. Vates strongly recommends updating as soon as possible.

The company also sets out steps that are distinct from installing that patch. It tells operators to keep Xen Orchestra off the internet and to place the instance on a dedicated management network, so the console is not reachable as a public service. It further recommends blocking traffic to and from a command-and-control address it associates with the activity it has seen, 91.211.251.112 on port 8001, and blocking Tor traffic used to reach a related onion service on port 3333. Those network controls are intended to interrupt the campaign Vates has identified; they are not the code fix.

Vates also suggests filtering empty login tokens at a web application firewall or reverse proxy, while warning that a narrow matching rule can be bypassed if an attacker uses another format. The patterns to match are in the advisory. A WAF rule of that kind is an interim control, not a replacement for the updated xo-server packages.

If Xen Orchestra has been compromised, Vates says all passwords and secrets used by Vates VMS should be rotated, including those for proxy, backup, S3, the root account and user accounts, because configuration theft and credential harvesting cannot be ruled out. Applying the patch closes this particular bypass. It does not restore trust in accounts, keys or hosts that may already have been taken over.

That combination — a management-plane flaw under active exploitation, a vendor patch, and a reminder that the patch is not a full recovery — is the same pattern TSN has reported in other recent cases, including Arista’s VeloCloud Orchestrator zero-day and a highly critical Drupal Commerce Core flaw that Drupal said was being exploited.

Vates’ indicators cover only the campaign it has identified

Vates is clear about the limits of detection. If the bypass succeeds, it says, there is no log that records the unauthenticated access. Administrators can still look for traces of the campaign the company has identified, but those traces are not a complete test.

On Xen Orchestra, Vates tells operators to look for a virtual machine named pivot2, and to monitor HTTP traffic for the malformed empty-object token described in the advisory. On XCP-ng hosts, it says to look for virtual machines configured with hvm_serial: file, again for a VM named pivot2, and for files including /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6.

Those indicators, Vates says, are tied to the attack it has identified so far. They cover only that campaign. Exploitation by other actors, using different methods and infrastructure, cannot be ruled out. The absence of these indicators, on its own, is not enough to conclude that no compromise has occurred.

That last point matters as much as the patch versions. A system can be updated and still have been entered earlier, and a system can be entered by someone who never leaves these particular files behind. The same caution applies more broadly when a vendor says a flaw is already being used in the wild, as Google did this week with an exploited Chrome XML bug: the useful work is to update, to restrict who can reach the service, and to look for intrusion rather than to treat a clean indicator check as a clearance.

No victim counts, named organisations, or attacker nationality or group have been published. Until a CVE is assigned, the identifier to use is VSA-2026-062. The immediate tasks remain those Vates has set out: install 6.9.1 or 6.10.0, keep Xen Orchestra off the public internet, and treat any suspected compromise as a credentials-and-host recovery problem, not only a packaging one.

Sources

1. Vates, “VSA-2026-062: Empty-object login token”, security advisory, published 10 November 2026. https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/
2. Vates, GitHub commit 50166fe, “fix(xo-server): validate authentication token IDs (#10748)”, 10 November 2026, 08:29 UTC (08:29 Europe/London). https://github.com/vatesfr/xen-orchestra/commit/50166fe3a49c02069d35ba9046ca4a1f77f4e11d

Related stories

CISA Adds Exploited Outlook Spoofing Flaw to Its KEV List

Arista’s VeloCloud Orchestrator zero-day is the closest recent TSN read: another management-plane flaw that the vendor said was already under attack, where patching and exposure of the console both matter.

Also relevant:

• Drupal Warns Highly Critical Commerce Core Flaw Is Being Exploited
• Chrome 157 Fixes Exploited XML Zero-Day CVE-2026-125350