Xen Orchestra auth bypass is being exploited, and the logs won't show it

Vates has confirmed that an authentication bypass in Xen Orchestra is being exploited in the wild, according to a BleepingComputer report published on November 10, 2026. The flaw is tracked as VSA-2026-062 and affects Xen Orchestra and the Xen Orchestra Appliance (XOA). No CVE identifier and no CVSS score have been assigned yet.

Xen Orchestra is Vates' web management platform for XCP-ng virtualization: VMs, hosts and pools. That's the console an admin uses to run the estate, which is why the vendor's own wording matters here. Vates says an adversary can bypass authentication and act with Admin privilege, and that a Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root.

What happened

The vulnerability was found by Filip Magic and Christoffer Olsen of TDC NET Security. Vates has shipped Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest), which include patched xo-server packages 5.211.2 and 5.213.1.

The company also published indicators of compromise from the campaign it has seen, and a warning that matters more than the list: exploitation won't leave identifiers in logs. The crafted cookies don't show up there, so detection has to come from HTTP monitoring.

How the bypass works

The bug sits in how Xen Orchestra handles authentication tokens sent through REST API requests, specifically the authentication cookie. Sending a cookie of authenticationToken=j:%7B%7D (the URL-encoded form of an empty JSON object) makes the platform fetch an existing authentication token and log the requester in as that token's owner. No credentials needed. Network access to the management interface is the only precondition the advisory describes.

From there, the /rest/v0/users/me/authentication_tokens REST API endpoint hands over reusable login token IDs, which keep the access going.

Impact

The blast radius is the virtualization layer. Admin on Xen Orchestra means control over the pools it manages, and Vates describes the chain ending in root on an XCP-ng node. Everything running on those hosts inherits that.

The IOCs Vates published point at a specific campaign, not the bug in general: connections to 91.211.251.112:8001 or ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333; HTTP requests carrying authenticationToken=j:%7B%7D or authenticationToken=j:{}; a VM named pivot2; VMs configured with the hvm_serial: file parameter; and files at /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6. Vates says these are tied to this campaign and may differ for other actors.

HackZoneLabs assessment

The interesting part of this one is the detection gap, not the severity. A pre-auth bypass that lands you as an existing token owner is bad enough on its own, but Vates is saying the request that does it looks unremarkable in the logs. In our view, any team that treats "nothing in the auth log" as evidence of no compromise on Xen Orchestra should drop that assumption for this bug. The IOC list is a starting point for the campaign Vates has seen; it isn't a detector for the vulnerability.

We'd also read the patch versions carefully rather than assuming a recent install is covered. The advisory names two xo-server package versions across two Xen Orchestra releases, and matching those exactly is the only way to know.

What remains unknown

Nobody has published how many installations were hit, or who. The advisory doesn't say. There's no CVE yet, so there's no public severity score to rank this against other work, and no independent write-up of the exploitation we've seen.

Vates' guidance is to install the update immediately. Where that isn't possible, restrict Xen Orchestra access to dedicated management networks and block the known malicious IP addresses. Anyone who thinks they were compromised should rotate the passwords and secrets used by their virtualization environments.

For defenders, the first checks are the ones the source supports: confirm the xo-server package version on every Xen Orchestra instance, look for the listed cookies in HTTP logs rather than auth logs, and check XCP-ng hosts for the named VM, the hvm_serial: file configuration and the four file paths. If any of those turn up, treat the host as owned and rotate from there.