CyberMerge
Exploited · Breaking

Attackers are exploiting a critical Xen Orchestra login bypass to take over XCP-ng virtualization hosts as root, plus a second bug Vates hasn't fixed yet

Vates says a threat actor is exploiting VSA-2026-062, a critical authentication bypass in Xen Orchestra, the web console that manages and backs up XCP-ng and XenServer pools. A cookie holding an empty object gets an outsider Admin rights, which Vates says can lead to code execution on managed pools and a full XCP-ng host takeover as root. The same attacker is also using a zero-day in VM import that still has no fix. No CVE has been assigned.

Nov 11, 2026 · 2 min read

What happened. Vates published advisory VSA-2026-062 on Nov 10, rated Critical, and says the flaw is actively exploited by an attacker that first operated from 91.211.251.112:8001 and a Tor onion service. Fixed builds are Xen Orchestra 6.9.2 (stable channel) and 6.10.1 (latest channel). The Xen Orchestra Appliance (XOA) and source installs are affected until updated. Per SecurityWeek, the same actor is also exploiting a second zero-day that needs admin rights and lets a malicious VM import compromise XCP-ng hosts; Vates says that fix is still being developed. Neither bug has a CVE or CVSS score yet.

How the bypass works. Xen Orchestra's REST API reads the login cookie authenticationToken=j:{} as an empty JSON object instead of a string. The token store treats that empty object as a "match anything" lookup and hands back the first saved token, so the request is logged in as that token's owner if it hasn't expired. From there the attacker can list reusable login tokens and act as an Admin across every pool the console manages.

Why this matters to an enterprise. Xen Orchestra is the control plane for XCP-ng, the open-source hypervisor many teams adopted as a VMware alternative after the Broadcom price changes. Owning it means owning every VM, the backup jobs and the credentials for backup targets (NFS, S3, Azure, SMB). Vates warns that unauthenticated access leaves no log, and that its indicators only cover this one campaign, so a clean IoC check does not prove a box is clean.

Do now. Update to 6.9.2 or 6.10.1 (xo-server 5.211.2 or 5.213.1); on XOA use the built-in updater, and on source installs pull the latest master and rebuild. Take the console off the internet and put it on a dedicated management network. Block the C2 addresses Vates lists and Tor egress. Hunt packet captures or proxy logs for authenticationToken=j:%7B%7D and look for a running VM named pivot2. If you were exposed, revoke sessions and API tokens and rotate pool, root, backup-remote and OTP secrets; Vates recommends a full reinstall after a confirmed compromise.

Sources