Vates has published security advisory VSA-2026-062 for an authentication bypass in Xen Orchestra and the Xen Orchestra Appliance (XOA), which Vates rates Critical. Vates says the vulnerability "is actively exploited by a threat actor." A crafted authentication cookie can let a request act with Admin privilege, and Vates warns that a Xen Orchestra compromise "can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root."
Vates published the advisory on 10 November 2026. The fixed releases are Xen Orchestra 6.9.2 (stable channel) and 6.10.1 (latest channel), with xo-server 5.211.2 (stable) and 5.213.1 (latest). No CVE identifier has been assigned, and Vates lists the CVSS 4.0 score as not available yet.
In the official XCP-ng forum announcement, Vates co-founder Julien Fontanet wrote that "most Xen Orchestra deployments are not exposed to the public Internet, which greatly reduces the likelihood of exploitation," and that urgent action is strongly advised where Xen Orchestra is reachable from the public Internet. If a managed service provider or hosting provider runs Xen Orchestra for you, use the supplier questions below.
Technical Information
Vates titles the issue "Empty-object login token." According to the advisory, REST cookie parsing turns a crafted authentication cookie into an empty object, which is passed to the token provider without a string check. The token lookup treats that object as an unfiltered query and returns the first stored token, and the request is authenticated as that token's owner if the token is unexpired. Vates adds that an authenticated route then returns reusable login token IDs. This post does not reproduce the cookie value or a request sequence.
Vates states the impact as the ability to "bypass authentication and perform actions with 'Admin' privilege," with possible code execution on managed pools and root on XCP-ng hosts. The advisory credits Filip Magic (@mad31k) and Christoffer Olsen of TDC NET Security and references pull request #10748 as the fix.
A separate Vates advisory published the same day, VSA-2026-063, covers a different privilege issue in Xen Orchestra's vm.import path, which Vates rates Important. It is not this bypass.
Affected Product Versions
| Product | Affected (per Vates) | Fix (per Vates) |
|---|---|---|
| Xen Orchestra, stable channel | Before 6.9.2 | 6.9.2 (xo-server 5.211.2) |
| Xen Orchestra, latest channel | Before 6.10.1 | 6.10.1 (xo-server 5.213.1) |
| Xen Orchestra Appliance (XOA) | Affected | Update to 6.9.2 or 6.10.1 via XOA > Updates |
| Xen Orchestra installed from source | Affected until updated | Latest master, then rebuild and restart xo-server |
BleepingComputer's 10 November report lists Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest) as the patched releases, alongside the same xo-server versions. Vates' advisory names 6.9.2 and 6.10.1, and this post follows Vates.
Exploitation Status
Vates says the vulnerability is actively exploited by a threat actor operating initially from 91.211.251.112:8001 and a Tor onion service on port 3333. Vates cautions that its detection guidance covers only the campaign identified so far, that exploitation by other actors using different TTPs and infrastructure "cannot be ruled out," and that the absence of its indicators alone "is not sufficient to conclude that no compromise has occurred."
No CVE identifier appears in Vates' advisory, and NVD keyword searches on 11 November 2026 returned no record. The issue is therefore not in CISA's Known Exploited Vulnerabilities catalog (catalogVersion 2026.11.10, checked 11 November 2026 at 08:23 Asia/Jerusalem UTC+2).
Workaround and Mitigation
The official fix is to update to Xen Orchestra 6.9.2 (stable) or 6.10.1 (latest). On XOA, Fontanet's forum post says to go to XOA > Updates in XO 5 and click Upgrade. Source installations should update to the latest master, then rebuild and restart xo-server.
Vates lists compensating options and strongly recommends updating as soon as possible:
- Do not expose Xen Orchestra to the Internet, and place it on a dedicated management network. Fontanet adds that a virtualization management plane "should never be exposed to the whole Internet, however up to date it is."
- Block ingress and egress traffic to the command-and-control addresses in the IoC table below, and block Tor traffic to the published onion service.
- Block the empty token in a WAF or reverse proxy as a temporary measure. Vates warns that such rules "can be bypassed using other formats."
- If Xen Orchestra has been compromised, rotate all passwords and secrets used by Vates VMS. Vates lists proxy, backup remotes (NFS, S3, Azure, SMB), root account and pool secret, user accounts, OTP secrets, and mail server configuration passwords. Fontanet's post also says to revoke all active sessions and API tokens. For a confirmed compromise, Vates recommends a full reinstallation.
Vates notes that a successful exploitation leaves no log of the unauthenticated access in Xen Orchestra. Detection relies on HTTP request monitoring and the host checks in the advisory.
Indicators of Compromise
The indicators below are those Vates published for the campaign it has identified. They are not a complete picture.
| Type | Value (from Vates VSA-2026-062) |
|---|---|
| C2 addresses | 91.211.251.112, 193.148.56.72, 37.221.208.216, 45.66.35.11, 64.65.0.120, 64.65.62.160, 89.47.51.90, 92.60.37.247 |
| Initial C2 | 91.211.251.112:8001; ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid[.]onion:3333 (via Tor) |
| Guest VM | A running VM named pivot2 |
| XCP-ng host | A VM with the hvm_serial: file platform parameter; -serial file: entries in /var/log/xensource.log* |
| XCP-ng host files | /etc/cron.d/zz-ustar2, /etc/cron.d/zz-ustar, /.ustar5, /.ustar6; Vates' check command also lists /etc/ld.so.preload |
Vates also publishes HTTP request patterns for the crafted cookie. Use those from the advisory directly.
What to Ask Your Suppliers Today
Managed service providers and hosting providers often run Xen Orchestra or XOA as the management plane for a customer's XCP-ng estate. If a third party operates that console for you, this bypass is a supplier-risk issue, not only an in-house patch ticket. Ask, in writing:
- Whether any Xen Orchestra or XOA instance used for your environment is, or has been, reachable from the public Internet, and for how long.
- Which channel and version is running now, including the xo-server build, and when 6.9.2, 6.10.1, or the fixed source build was applied.
- Whether they have checked Vates' indicators, HTTP logs, and the XCP-ng host checks in VSA-2026-062, and what they found.
- Whether active sessions and API tokens have been revoked and Vates VMS secrets rotated since the disclosure.
- Whether Xen Orchestra sits on a dedicated management network or behind a VPN.
If you run Xen Orchestra yourself, apply the fixed release first, then run the same review. Fontanet's point about limited Internet exposure is reassuring only once you have confirmed it for your own deployment.
If your team needs help reviewing an internet-exposed or suspected-compromised Xen Orchestra deployment, Talk to an expert.
Sources
- VSA-2026-062: Empty-object login token, Vates, published and updated 10 November 2026; checked 11 November 2026 at 08:23 Asia/Jerusalem UTC+2.
- VSA-2026-063: Crafted keys through XO vm.import privilege, Vates, 10 November 2026; a separate issue.
- Security: VSA-2026-062: critical Xen Orchestra vulnerability fixed, please update, XCP-ng forum post by Julien Fontanet (Vates), 10 November 2026.
- Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers, BleepingComputer, 10 November 2026. Its patched-release figures (6.9.1 / 6.10.0) differ from Vates' advisory (6.9.2 / 6.10.1).
- CISA Known Exploited Vulnerabilities catalog JSON — catalogVersion 2026.11.10, dateReleased 2026-11-10T19:03:29Z; no Vates or Xen Orchestra entry. Checked 11 November 2026 at 08:23 Asia/Jerusalem UTC+2.
- NVD — keyword searches for Xen Orchestra (published 1–11 November 2026) and VSA-2026-062 returned no records on 11 November 2026.



