What Happened
A critical Xen Orchestra authentication bypass is being actively exploited, and for an MSP that means a client's virtualization estate can be taken over without a valid password. BleepingComputer reports the flaw can grant administrator privileges and allow takeover of XCP-ng virtualization hosts. Hacker News reports that Vates VMS, the French software company behind Xen Orchestra, warned of the vulnerability and said it is being actively exploited in the wild.
An authentication bypass sits in front of everything the host runs. If an attacker lands administrator rights on the management layer, every virtual machine underneath is in scope: file servers, domain controllers, line of business applications, and any backup that lives on the same platform. For an MSP that is not one ticket. It is every client on that host, at once.
The flaw does not yet have a CVE identifier. It is tracked as VSA-2026-062. Vates VMS published an alert about it, and that alert is the place to start. As a standing practice, read the vendor guidance before you change anything, because the order of operations matters when you suspect an authentication bypass has already been used.
Timeline
- November 10, 2026: BleepingComputer publishes a report that the flaw is being actively exploited and that it can allow takeover of XCP-ng virtualization hosts.
- November 10, 2026: Hacker News publishes a report that Vates VMS warned of the flaw, saying it is being actively exploited in the wild and tracking it as VSA-2026-062.
Who Is Affected
The named affected products are Xen Orchestra and XCP-ng virtualization hosts. Anyone running Xen Orchestra as the management layer for XCP-ng, whether on their own infrastructure or on behalf of clients, is in the blast radius. An MSP that hosts client workloads on XCP-ng through Xen Orchestra should treat this as a live incident until it has confirmed otherwise.
If you do not run Xen Orchestra, this specific flaw does not apply to you. That is a fair reading of the reports. It is not a reason to close the page. The class of attack, an authentication bypass on an internet reachable management interface, is one that every MSP should have an answer for, because the management layer is where the damage gets multiplied.
Technical Details
CVE: none assigned at the time of the reports. Vendor tracking identifier: VSA-2026-062. Product: Xen Orchestra. Affected systems: XCP-ng virtualization hosts. Attack vector: REST cookie parsing.
Vates VMS said in an alert, as reported by Hacker News, that REST cookie parsing turns authenticationToken=j:%7B%7D into {}.
That is the extent of the technical detail the public reports give. No CVE has been assigned, and the reports do not name specific affected versions. The Vates VMS alert is where those details belong.
Why the Xen Orchestra Authentication Bypass Matters to MSPs
Virtualization management is a single door to many rooms. One set of administrator credentials on the Xen Orchestra layer controls the hypervisor, the storage, the networks and every guest. An authentication bypass removes the need for the credentials entirely, which is why this class of flaw is more dangerous than a bug that needs a valid login to exploit.
The recovery cost is what turns it into a business problem. Rebuilding a single server is a known quantity. Rebuilding every guest on a host, re-establishing trust in the management layer, and explaining to each client why their systems were down at the same time is a different scale of work. MSPs carry that scale directly, and it arrives all at once.
Detection is the harder half. Authentication bypass leaves you looking for sessions that should not exist, accounts that changed, and API calls that do not match normal patterns. In general, the earlier you look, the more you have to work with, which is why log preservation comes before remediation.
What MSPs Should Do
Work from the Vates VMS alert and your own incident response plan. The steps below are the standard sequence for an authentication bypass on a management interface, applied in order.
- Confirm whether Xen Orchestra is in your stack or in a client's stack, and where it is reachable from.
- Read the Vates VMS alert and apply the vendor mitigation or fix as directed.
- If the instance is reachable from the internet, restrict access at the network layer now, while you work.
- Preserve evidence before you change anything. Export authentication and audit logs from Xen Orchestra and the hosts it manages.
- Review for administrator access you did not authorize, including new accounts, changed roles and unexpected API activity.
- Rotate credentials and API tokens that touch Xen Orchestra and the XCP-ng hosts it manages.
- Check whether any host or guest is running a version named in the vendor advisory and schedule the update.
- If you confirm compromise, contain the host, rebuild it from a known good image, and restore client workloads from a clean backup.
- Tell the affected client what you found, what you did and what you still need to verify.
How EnterProtect Helps
EnterProtect does not detect, block or prevent this attack. No backup vendor can claim that honestly. What EnterProtect backup does is keep clean, restorable copies of the systems your clients depend on, separate from the infrastructure under attack.
That separation is the point. If a virtualization host has to be rebuilt or abandoned, EnterProtect recovery is what gets a client running again, on a schedule you can plan around instead of a schedule the attacker sets.
For an MSP, the question after an incident like this is not whether the flaw was clever. It is whether you had a copy that was not touched. EnterProtect is in the business of being that copy.
Frequently Asked Questions
What Is This Xen Orchestra Flaw?
It is a critical flaw in Xen Orchestra that lets an attacker bypass authentication and reach administrator privileges, according to BleepingComputer. A successful attack can allow takeover of XCP-ng virtualization hosts. Vates VMS, the company behind Xen Orchestra, says the flaw is being actively exploited in the wild.
Is There a CVE for This Flaw?
No. The reports say the flaw does not yet have a CVE identifier. Vates VMS tracks it as VSA-2026-062. Use that identifier when you search vendor documentation or ask your contacts about it.
Which Versions of Xen Orchestra Are Affected?
The public reports do not name specific versions. Vates VMS tracks the flaw as VSA-2026-062, and the vendor alert is the authoritative source for affected versions and fixes. Treat any Xen Orchestra instance that manages XCP-ng hosts as needing review until the vendor guidance says otherwise.
What Can an Attacker Do After Exploiting It?
They can gain administrator privileges on Xen Orchestra and take over XCP-ng virtualization hosts, according to BleepingComputer. From that position, every guest on the host is reachable. That includes file servers, applications and any backup stored on the same platform.
I Run XCP-Ng but Not Xen Orchestra. Am I Affected?
The reports name Xen Orchestra as the vulnerable product and XCP-ng virtualization hosts as what can be taken over. If you do not run Xen Orchestra, this specific flaw does not apply to you. The broader lesson, that a management interface is worth defending like a crown jewel, still does.
How Do I Check Whether My Xen Orchestra Instance Was Compromised?
Preserve logs first, before you change anything. Then look for administrator sessions you did not start, accounts or roles that changed, and API activity that does not match normal usage. Rotate credentials and tokens that touch the instance and the hosts it manages, and treat any confirmed compromise as a containment and rebuild exercise.
Sources
- Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers (Bleepingcomputer)
- Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access (Hackernews)