Is your Xen Orchestra exposed to the VSA-2026-062 login bypass?
Vates published VSA-2026-062 on 10 November 2026: an actively exploited, Critical authentication bypass in Xen Orchestra and the Xen Orchestra Appliance. A crafted cookie gives Admin access, which can lead to root on managed XCP-ng hosts. No CVE or CVSS score yet. Update to Xen Orchestra 6.10.0 or 6.9.1 now.
Actively exploited. Critical per Vates. No CVSS score assigned yet
Vates says VSA-2026-062 is actively exploited by a threat actor operating from 91.211.251.112:8001 and an onion address over Tor. Vates says: "We classify the impact as Critical." No score has been assigned (the advisory's CVSS 4.0 field says Not available yet) and there is no CVE. The flaw is in xo-server, the Xen Orchestra back end, not in the XCP-ng hypervisor. A successful attack leaves no log of the unauthenticated access in Xen Orchestra itself. Update now, take Xen Orchestra off the internet, and hunt using the Vates IOCs below. Not in CISA KEV when checked at 17:07 GMT on 10 November 2026.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 10 November 2026, 18:05 GMT.
At a Glance
Based on the Vates advisory VSA-2026-062 as of 10 November 2026. Last updated 10 November 2026, 18:05 GMT.
Critical (Vates)
Vates classifies the impact as Critical. CVSS 4.0 is not available yet and no CVE is assigned.
Actively exploited
Vates names attacker infrastructure. Not in CISA KEV when checked on 10 November.
Admin, then root on hosts
Admin in Xen Orchestra, which can lead to code execution on managed pools and root on XCP-ng hosts.
xo-server 5.213.1 or 5.211.2
Shipped in XO 6.10.0 (latest) and 6.9.1 (stable) as updated on 10 November. Check the xo-server version, not just the XO label.
Vates publishes VSA-2026-062, Empty-object login token, and classifies it Critical.
Vates says it is actively exploited and publishes attacker infrastructure and IOCs.
Fixes ship as Xen Orchestra 6.10.0 (latest) and 6.9.1 (stable). No CVE or CVSS yet.
Update, take Xen Orchestra off the internet, block the C2 and hunt with the Vates IOCs.
Affected and fixed versions (Vates wording)
| Product | Affected | Fix |
|---|---|---|
| Xen Orchestra (xo-server) | Vates: "xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest): Affected." | Xen Orchestra 6.10.0 (latest channel), with xo-server 5.213.1, or Xen Orchestra 6.9.1 (stable channel), with xo-server 5.211.2. |
| Xen Orchestra Appliance (XOA) | Vates: Affected. | Update XOA through its updater to the fixed release on your channel: 6.10.0 (latest) or 6.9.1 (stable). |
The affected line is quoted exactly from the Vates advisory. It does not match the Resolution list exactly (5.213.2 against 5.211.2); we follow the Resolution list. Vates says security fixes are delivered to both the latest and the stable channel.
The XO version label is not enough
According to the Xen Orchestra changelog and our detection pack research, the XO 6.10.0 and 6.9.1 labels first shipped with vulnerable xo-server builds (5.213.0 on 29 October and 5.211.1 on 5 October). Confirm the xo-server version itself is 5.213.1 or 5.211.2. Our pack documents that installs from sources can still report 5.213.0 after the fix, so for those confirm the source tree includes commit 50166fe3 and that you rebuilt.
Why MSPs should move first
Xen Orchestra is the management layer for XCP-ng. Vates says compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root. If you host client VMs on XCP-ng, one exposed Xen Orchestra can put every managed pool at risk.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Vates' advice and our advice are labelled separately.
Update and restrict
- Vates: update to Xen Orchestra 6.10.0 (latest) or 6.9.1 (stable), or the matching XOA update, as soon as possible.
- Vates: do not expose Xen Orchestra to the internet. Put it on a dedicated management network.
- Vates: block 91.211.251.112 for ingress and egress, and block Tor traffic to the onion C2.
- Our advice: allow access only from a VPN or jump host, and list every XO and XOA you run for clients.
Hunt and contain
- Vates: search HTTP, proxy or WAF traffic for the empty-token cookie patterns.
- Vates: look for a VM named
pivot2and VMs usinghvm_serial: file. - Vates: check XCP-ng hosts for
/etc/cron.d/zz-ustar,/etc/cron.d/zz-ustar2,/.ustar5and/.ustar6. - Vates: if compromised, rotate all passwords and secrets. Our advice: revoke XO tokens and investigate the hosts.
Proactive: Update and Lock Down
Vates strongly recommends updating as soon as possible. The mitigations reduce risk until you can.
Update Xen Orchestra now
Vates: update to Xen Orchestra 6.10.0 on the latest channel (xo-server 5.213.1) or 6.9.1 on the stable channel (xo-server 5.211.2). On the Xen Orchestra Appliance, use the built-in updater. Then confirm the xo-server version is 5.213.1 or 5.211.2, because the XO label alone does not prove the fix. See the Vates advisory.
Take Xen Orchestra off the internet
Vates: do not expose Xen Orchestra to the internet, and put it on a dedicated management network. Our advice: allow access only through a VPN or jump host, and check firewall NAT rules and cloud security groups across every client.
Block the known C2
Vates: add ingress and egress filter rules to block 91.211.251.112, and block Tor traffic to stop communication with the onion address in the IOCs section. Vates strongly recommends immediate blocking because ongoing malicious activity cannot be ruled out.
Optional: block the empty token at a proxy
Vates: you can block the empty-token cookie patterns in a WAF or reverse proxy. Vates warns to be cautious with regex, because the rule can be bypassed using other formats. Treat this as a stopgap, not a fix.
Inventory every instance
Our advice: list every Xen Orchestra and XOA you run, for yourself and for clients, with its version, channel and whether it was reachable from the internet. Anything reachable before the update should be hunted.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams and MSPs. Check versions offline and hunt for the Vates IOCs. Everything is read-only.
check-xen-orchestra.sh
Read-only offline checker. It compares the xo-server version you give it, or a CSV inventory, against the fixed builds Vates names, and scans saved proxy, WAF or firewall logs and the saved output of the Vates host checks for the published IOCs. It never contacts Xen Orchestra.
bash check-xen-orchestra.sh --xo-server 5.213.1 --edition xoa --host xo-client-a
# Whole estate, plus saved proxy logs and Vates host-check output
bash check-xen-orchestra.sh --csv inventory.csv \
--scan proxy-access.log --scan xcpng-host1-checks.txtCheck-XenOrchestra.ps1
The same checks in PowerShell 7, with identical output and exit codes. It also runs under PowerShell on Linux.
pwsh -File Check-XenOrchestra.ps1 -Csv inventory.csv -Scan proxy-access.logKQL and Sigma
13 KQL hunts for Microsoft Sentinel and Defender (Q1 to Q8, Q8b and Q9 to Q12): finding XO servers and their exposure, the empty-object cookie in WAF, IIS and proxy logs, calls to the token listing route, the C2 address, Tor use, the host files and XCP-ng log artefacts, and shells started by xo-server. 4 Sigma rules cover the cookie patterns, the C2 address and the host files. Each hunt is tagged as a Vates indicator or our own logic. None of the KQL has been run against a live tenant yet.
Verdicts
- PATCHEDEvery row on a fixed xo-server build Vates names (5.213.1 or 5.211.2).
- VULNERABLEAny row on an affected xo-server build.
- UNKNOWNUnreadable version or edition, no version given, or a scan with no match.
- NEEDS MORE INFOThe version cannot prove the fix: an XO 6.9.1 or 6.10.0 label alone, a sources install on 5.213.0, or a build Vates did not name.
- IOC MATCHA Vates indicator was found in the files you scanned (overrides the other verdicts).
Exit codes
| Code | Meaning |
|---|---|
| 0 | PATCHED |
| 1 | VULNERABLE |
| 2 | UNKNOWN |
| 3 | NEEDS MORE INFO |
| 4 | IOC MATCH |
| 5 | Usage or read error |
Inventory mode exits with the worst row. MSPs can use the exit code in RMM or scheduled jobs.
Know the limits
- Both checkers are read-only and offline. They only read the version strings and files you give them, send no network traffic, write nothing and contain no exploit payloads.
- Xen Orchestra keeps no log of the bypass (Vates). Cookie hunts only work where a proxy or WAF you control ends TLS and logs the Cookie header.
- The IOCs are the ones Vates published and cover only the known campaign. Encoded or spaced cookie variants, other
/.ustar*files and Tor logic are our own patterns and are labelled that way. - None of the KQL has been run against a live tenant. Q11 assumes XCP-ng hosts forward the relevant xensource log lines to your SIEM, which we have not verified.
- Whether later xo-server builds keep the fix is not confirmed, so the checker returns NEEDS MORE INFO for builds Vates did not name.
What is in the pack
| File | What it does |
|---|---|
| check-xen-orchestra.sh | Offline checker for Linux and macOS (bash) |
| Check-XenOrchestra.ps1 | The same checker in PowerShell 7 |
| KQL (13 hunts) | Microsoft Sentinel and Defender hunts Q1 to Q12, including Q8b |
| Sigma (4 rules) | Cookie, C2 address and host file rules, plus Kusto conversions |
| tests/ | Fixtures, bash and Pester tests and a sandboxed no-network run |
| README.md | Verified facts, Vates advice versus ours, limits and usage |
Reactive: IOCs and How to Hunt
Vates published these indicators for defenders. They cover only the campaign identified so far. CybaOps can run these hunts across your estate or your clients'.
HTTP, proxy and WAF logs
Vates says there is no log of the unauthenticated access in Xen Orchestra itself, so search HTTP traffic, reverse proxy or WAF logs, or packet captures, for these cookie patterns. This only works where a proxy or WAF you control ends TLS and logs the Cookie header (KQL Q3 to Q5).
authenticationToken=j:%7B%7D
authenticationToken=j:{}Attacker infrastructure
Search firewall, proxy and DNS logs for connections to the infrastructure Vates names:
91.211.251.112:8001
ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333 (via Tor)Suspicious VMs
Vates: look for a VM named pivot2 among running VMs, and for VMs using the hvm_serial: file platform parameter.
Files on XCP-ng hosts
Vates: look for /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6. The read-only checks Vates published are below. Its file check also lists /etc/ld.so.preload; Vates does not name that file as an IOC, so treat it as a hunt hint and review any entries you cannot explain.
# On each XCP-ng host (read-only checks published by Vates)
xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'
zgrep -- '-serial file:' /var/log/xensource.log*
ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*If you find signs of compromise
- Vates: rotate all passwords and secrets used by Vates VMS, such as proxy, backup, S3, root and user accounts. Configuration exfiltration and credential harvesting cannot be ruled out.
- Our advice: revoke every Xen Orchestra authentication token, and review Xen Orchestra users and their permissions.
- Our advice: isolate and investigate the affected XCP-ng hosts and VMs, and keep HTTP logs, captures and host evidence.
- Our advice: rebuild hosts where root compromise is confirmed or cannot be ruled out.
No IOCs does not mean clean
Vates says exploitation by other threat actors using different methods and infrastructure cannot be ruled out, and the absence of these IOCs alone is not enough to conclude that no compromise has occurred. Updating stops new use of this flaw. It does not remove tokens, VMs, cron jobs or files already planted.
Xen Orchestra VSA-2026-062 FAQ
Short answers based on the Vates advisory as of 10 November 2026.
What is VSA-2026-062?
VSA-2026-062 is a Vates security advisory, titled Empty-object login token, published and updated on 10 November 2026. It covers an authentication bypass in xo-server, the Xen Orchestra back end, including the Xen Orchestra Appliance (XOA). The flaw is in Xen Orchestra, not in the XCP-ng hypervisor; XCP-ng hosts are what an attacker reaches next. Vates says: We classify the impact as Critical. Vates also says it is actively exploited.
Does it have a CVE or a CVSS score?
Not yet. No score has been assigned: the advisory lists no CVE, and its CVSS 4.0 field says Not available yet. Critical is Vates' own classification on its severity scale, not a CVSS score, and we add no severity label of our own. We will add a CVE and score only when Vates or a CVE record publishes them.
How does the bypass work, at a high level?
Vates says a crafted authentication cookie sent to Xen Orchestra's REST interface reaches the token check in a form it does not expect, and Xen Orchestra then authenticates as the owner of an existing token, if that token is unexpired. The attacker can then obtain reusable login tokens. No password is needed, but Xen Orchestra must be reachable. We do not publish exploit steps.
What can an attacker do with it?
Vates says an adversary can bypass authentication and perform actions with Admin privilege, and that Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root. For MSPs that host client VMs on XCP-ng, that means every managed pool is at risk.
Is it being exploited?
Yes. Vates says: This vulnerability is actively exploited by a threat actor operating from 91.211.251.112:8001 and ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333 (via Tor). It was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 17:07 GMT on 10 November 2026 (catalogue 2026.11.09). KEV lists CVEs, so it cannot list this issue until one is assigned. Update now regardless.
Which versions are affected and which fix it?
Vates lists as affected: xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest), and the Xen Orchestra Appliance. Its Resolution list names the fixed packages as xo-server 5.213.1 (latest channel) and xo-server 5.211.2 (stable channel), in Xen Orchestra 6.10.0 and 6.9.1 as updated on 10 November. The Affected line and the Resolution list do not match exactly (5.213.2 against 5.211.2); we follow the Resolution list.
Does an XO 6.10.0 or 6.9.1 label prove we are patched?
No. According to the Xen Orchestra changelog and our detection pack research, those release labels first shipped on 29 October (6.10.0, with xo-server 5.213.0) and 5 October (6.9.1, with xo-server 5.211.1), before the fix. Check the xo-server version: 5.213.1 or 5.211.2. Our pack also documents that installs from sources can still report xo-server 5.213.0 after the fix; for those, confirm your source tree includes commit 50166fe3 and that you rebuilt. Whether later xo-server builds keep the fix is not confirmed yet.
Will Xen Orchestra logs show an attack?
No. Vates says a successful exploitation leaves no log of the unauthenticated access in Xen Orchestra. Look for it in HTTP traffic using the cookie patterns Vates published, and on the XCP-ng hosts using the host IOCs. Xen Orchestra usually serves HTTPS itself, so cookie hunts only work where a proxy or WAF you control ends TLS and logs the Cookie header, or in captures taken after TLS is ended.
If we find no IOCs, are we safe?
Not necessarily. Vates says its IOCs cover only the campaign identified so far, other actors may use different methods and infrastructure, and the absence of these IOCs alone is not enough to conclude there was no compromise. Update, keep Xen Orchestra off the internet and keep hunting.
What should we do if we find signs of compromise?
Vates says to rotate all passwords and secrets used by Vates VMS, such as proxy, backup, S3, root and user accounts, because configuration exfiltration and credential harvesting cannot be ruled out. Our advice on top: revoke all Xen Orchestra authentication tokens, isolate and investigate the affected XCP-ng hosts and VMs, and keep logs and captures.
Who found it?
Vates credits security researchers with the discovery.
Protect Your Virtualisation Estate, and Your Clients'
CybaOps monitors your servers, endpoints, hypervisors and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- Vates: VSA-2026-062, Empty-object login token (published and updated 10 November 2026)
- Vates: Security advisories index
- Xen Orchestra documentation: Updater
- BleepingComputer: Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers
- CISA: Known Exploited Vulnerabilities catalogue (checked 10 November 2026, 17:07 GMT; catalogue 2026.11.09)
Related threat guides: Barracuda CVE-2026-116606 and CVE-2026-111560 and ConnectWise cloud backup compromise. All threat guides.