Vates warns Xen Orchestra auth bypass is being exploited, with no CVE assigned

Vates, the company behind Xen Orchestra, says a threat actor has been exploiting a critical authentication bypass in the product to gain administrator privileges. The vendor's warning, reported by SecurityWeek on 11 November 2026, covers Xen Orchestra releases before 6.9.2 (stable) and 6.10.1 (latest), plus the Xen Orchestra Appliance, which bundles Xen Orchestra.

Xen Orchestra is a web-based backup, management and disaster recovery console for XCP-ng and XenServer environments. It runs agentless across hosts, VMs, storage and pools, which is the part that matters here: whoever holds admin in it holds the virtualization layer underneath.

What happened

According to Vates, the actor operated initially from 91.211.251.112:8001 and via the Tor network. The company disclosed a second vulnerability that the same actor used after getting admin, one that allows malicious VM imports that could compromise XCP-ng hosts. A fix for that second flaw is still being developed.

No CVE identifier has been assigned to either defect. Vates has published indicators of compromise tied to the observed attacks and says they're limited to this campaign. It also warns that other actors using different tooling can't be ruled out, and that missing the IoCs doesn't prove a host is clean.

How the bypass works

The flaw sits in the REST authentication mechanism. An authentication token is turned into {} and then treated as an unfiltered lookup, so the first token returned by token collection is used. If that token hasn't expired, the provider authenticates as its owner. Reusable login token IDs end up exposed, and an unauthenticated request can land in an admin session.

That's the whole trick, as far as the vendor's description goes. It doesn't need credentials, and it doesn't need a payload beyond an empty token. Vates' suggested WAF rule, blocking the empty token, follows directly from that.

The impact statement from Vates is blunt: compromise "can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root."

HackZoneLabs assessment

The logging gap is the part we'd weigh heaviest. Vates says unauthorised access isn't logged, which means a successful bypass leaves no record in the product itself. An operator who patched this morning still can't answer whether anyone walked through the door last week, and the vendor's own IoC caveat says as much. In our view, that pushes the question from "are we patched" to "can we prove we weren't hit", and for most shops the honest answer will be no.

The second flaw deserves equal attention. It's exploited by an actor who already had admin, and there's no fix yet. Patching the bypass closes the front door but doesn't remove a capability someone with admin already has. We'd treat any instance that was reachable from untrusted networks as suspect until someone can show otherwise.

The absence of a CVE is a practical annoyance rather than a technical one. It makes the flaw harder to track in vulnerability feeds and scanner output, so teams relying on CVE-driven triage may not see it at all. We'd not wait for an identifier.

What remains unknown

The advisory doesn't say how many instances were hit, over what period, or whether the actor reached code execution or node takeover in any specific case. It doesn't describe the second flaw's mechanism beyond malicious VM imports, and it gives no timeline for its fix. Whether the empty-token behaviour is reachable in configurations other than the default isn't stated either.

What defenders can check first

Vates' recommendations, in the order they matter:

• Patch to 6.9.2 (stable) or 6.10.1 (latest), and cover Xen Orchestra Appliance deployments too.
• Put Xen Orchestra instances behind a dedicated network rather than exposing them.
• Block the IP addresses and domains tied to the known malicious activity.
• Add a WAF rule that blocks the empty token.
• Rotate every credential that could plausibly have been exposed.

For a confirmed compromise, Vates says a full reinstallation is recommended, because cleanup alone can't guarantee removal of all backdoors. Given the missing logs, we'd read "confirmed" loosely: if an instance was exposed and unpatched, the reinstatement argument is worth having before you find evidence.