Vulnerabilities
Xen Orchestra auth bypass exploited to take hosts
Attackers are exploiting a critical, unlogged authentication bypass in Xen Orchestra (VSA-2026-062) to seize admin and XCP-ng hosts. What to do now.
A console that manages virtual machines holds the keys to every one of them. Xen Orchestra, the web platform that Vates builds for XCP-ng and XenServer virtualization, can start, stop, clone, back up and restore every VM (virtual machine) in a datacenter, and it stores the credentials for the physical hosts underneath. Whoever controls that console controls the whole estate.
That console is now being broken into, and the break-in leaves no trace. On November 10, 2026, Vates warned that a threat actor is exploiting a critical authentication bypass in Xen Orchestra, tracked as VSA-2026-062, to gain administrator rights with no login at all. The company says the unauthorized access is not recorded anywhere in Xen Orchestra's own logs, so an administrator looking only at the application cannot tell whether they were hit.
How it works
Xen Orchestra sits above a pool of XCP-ng or XenServer hosts and drives them through a web interface and a REST (Representational State Transfer) application programming interface. Requests to that interface carry an authentication token in a cookie, and the server looks the token up to decide who is calling.
The bypass abuses how that token is parsed. A request can send the cookie value j:{}, which Xen Orchestra turns into an empty object instead of a string. The authentication code accepts the object without checking its type, and the token lookup, given nothing to match on, returns the first token it finds. If that token belongs to a real, unexpired session, the attacker is now authenticated as its owner. A separate listing route then hands over reusable login token IDs. No password, and no valid token of the attacker's own.
Administrator on the console is not the finish line. Vates says the same actor chains a second, still unpatched flaw, tracked as VSA-2026-063, that abuses the VM import feature. Import normally brings a disk image into a pool. Driven from an admin session, it runs attacker code on the XCP-ng hosts themselves as root, which is full control of the machine and every VM on it. The advisory adds that even the bypass on its own can lead to code execution on managed pools and a complete host takeover.
The hard part is that none of the unauthenticated access is logged. Xen Orchestra records actions taken by a signed-in user, but the forged session this flaw creates never shows up as a failed login or an odd sign-in. An administrator cannot scope the damage from the console and has to hunt on the hosts instead, in files such as /var/log/xensource.log, for the activity that followed.
What is happening
Vates published VSA-2026-062 on November 10, 2026, rated Critical, with no CVE identifier assigned yet, so the advisory number is the only name it has. SecurityWeek reported the attacks the next day. The flaw was reported by researchers at TDC NET Security, and Vates confirmed it is being exploited in the wild, not only in a lab.
The first observed activity came from the address 91.211.251.112 on port 8001 and from a Tor hidden service on port 3333. On compromised systems the actor created a VM named pivot2, set the hvm_serial parameter to file on VMs, and left persistence behind: cron jobs at /etc/cron.d/zz-ustar, marker files /.ustar5 and /.ustar6, and a library preload entry at /etc/ld.so.preload. Vates published these indicators of compromise (IOC), a wider list of attacker IP addresses, and the raw request pattern authenticationToken=j:%7B%7D so defenders can search their proxies and web server logs for it.
Vates is clear that the published indicators describe one campaign. A different actor could use different infrastructure, so the absence of these markers does not prove a system is clean.
Separately, Vates issued two Critical XCP-ng advisories on November 3, VSA-2026-055 and VSA-2026-056, covering host-level memory flaws that can reach Dom0, the control domain that runs each host. They are not part of this campaign, but anyone patching Xen Orchestra is already working in the same systems, so fold the host updates into the same maintenance.
What to do
Update Xen Orchestra first. The fix is in 6.10.1 on the latest channel and 6.9.2 on the stable channel, which ship xo-server 5.213.1 and 5.211.2 respectively. Installs built from source should move to the latest master. The Xen Orchestra Appliance contains the same code and needs the same update.
Take the console off the public internet. Because the bypass needs no account, anyone who can reach the web interface can try it, so put Xen Orchestra on a dedicated management network reached only through a VPN (virtual private network) or an allowlist of admin addresses. If you cannot patch within the hour, a web application firewall rule can block the token patterns authenticationToken=j:%7B%7D and authenticationToken=j:{}, but Vates warns the value can be re-encoded to slip past a regular expression, so treat that as a short delay, not a fix.
Assume compromise if the console was reachable from the internet while unpatched. The access leaves no log to clear you, so the safe default is that it was used. Apply the published IOCs: block the listed attacker IP addresses in both directions and block the Tor address, then look on your hosts for the VM named pivot2, for VMs with hvm_serial set to file, and for the zz-ustar cron jobs, the .ustar marker files and the ld.so.preload entry. Read /var/log/xensource.log for the imports and VM operations that came after the break-in.
Rotate the secrets the console holds. Xen Orchestra stores credentials for the systems it manages, so a patch alone does not undo exposure. Rotate the pool secret, the root passwords on the hosts, backup remote credentials, user account passwords, one-time-password secrets and mail server credentials, along with any API tokens the console keeps for your hypervisors.
Review administrator accounts and active sessions last. Check the admin list for any account you did not create, then invalidate existing sessions and tokens so a stolen token ID stops working. Where compromise is confirmed, Vates recommends a full reinstallation, because a backdoor planted at the host level may survive a lighter cleanup.
A management plane that was reachable from the internet is the kind of exposure our attack surface management work is built to find before an attacker does, and rebuilding one that sits behind a VPN instead is where our platform and cloud engineering team helps. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Vates advisory VSA-2026-062, SecurityWeek on the Xen Orchestra attacks, SC World, Rescana analysis, Vates security advisories index.