Attackers are actively exploiting a critical authentication bypass in Xen Orchestra, the management platform for XCP-ng virtualization hosts, to gain administrator control and potentially root access to the underlying nodes.
The Xen Orchestra project disclosed the flaw in advisory VSA-2026-062 and released fixes on the same day it confirmed exploitation. The advisory has no CVE identifier or CVSS score yet.
A Crafted Cookie With an Empty JSON Object Defeats Authentication
The vulnerability allows an attacker to bypass authentication by sending a crafted cookie that contains an empty JSON object, in the form authenticationToken=j:{}. A server that accepts the malformed value treats the request as authenticated, giving the attacker Admin privileges in Xen Orchestra. From there, the attacker can potentially reach root on XCP-ng nodes.
Remote attackers with network access to the management interface can therefore hijack virtual machine hosts. Management planes for hypervisors concentrate control over every guest on a node, so a bypass at this layer exposes far more than a single application.
Fixed Versions for Stable and Latest Branches
The project fixed the flaw in Xen Orchestra 6.9.1 on the stable channel and 6.10.0, with the matching xo-server releases 5.211.2 and 5.213.1. The issue affects both Xen Orchestra built from source and the Xen Orchestra Appliance, known as XOA. The project advises administrators to patch immediately, or to restrict the management interface to a dedicated network if they cannot.
Filip Magic and Christoffer Olsen of TDC NET Security found the vulnerability.
Indicators of Compromise Defenders Can Check
The advisory lists several indicators tied to the observed attacks. They include the IP address 91.211.251.112 on port 8001 and an onion domain. On compromised systems, defenders may find a virtual machine named “pivot2” and files at /etc/cron.d/zz-ustar*, /.ustar5 and /.ustar6.
The persistence artifacts, a cron entry plus hidden files in the filesystem root, point to attackers who intended to retain access rather than simply probe the system. A VM named “pivot2” suggests the compromised hypervisors were being used as pivot points for further activity, though the advisory does not describe what the attackers did after gaining access.
Separate From the Earlier Xen Hypervisor Flaws
This vulnerability is distinct from the Xen hypervisor VM-memory flaws that were disclosed earlier in the month. Those affect the hypervisor itself; VSA-2026-062 affects the Xen Orchestra management software layered on top of XCP-ng. Administrators running both should track the two issues separately, since fixing one does not address the other.
Management-Plane Exposure and the Wider Pattern
Authentication bypass bugs in management software have become a recurring route into enterprise infrastructure. Virtualization consoles are attractive because one successful login can unlock many workloads. The practical risk rises when a management interface is reachable from untrusted networks, which is why the advisory’s alternative to patching is network isolation.
Because the project has confirmed exploitation, organizations running Xen Orchestra or XOA should treat the update as urgent and check for the published indicators on any instance that was reachable before patching. Updating closes the bypass but does not remove persistence that an attacker may have already established, so reviewing for the cron files and hidden binaries is a necessary second step.
The lack of a CVE number at publication means that automated vulnerability scanners keyed to CVE feeds may not flag affected installations yet, leaving manual version checks as the reliable method for now.
Practical Exposure Questions for Xen Orchestra Administrators
The advisory’s remedy options point to the key exposure question: whether the Xen Orchestra web interface is reachable from networks the organization does not control. The bypass needs only network access to the management interface, so an instance reachable from the internet is in a different risk category from one on an isolated management network.
Administrators who already updated before the exploitation was confirmed still have a reason to review their systems. The published indicators, including the cron entries under /etc/cron.d, the /.ustar5 and /.ustar6 files and the VM named “pivot2”, are quick to check and would show whether an attacker used the flaw before the fix was installed.
