Attackers are exploiting a critical authentication bypass in Xen Orchestra, the web console used to run XCP-ng virtualisation estates, to gain administrator rights without a password. Vates has shipped fixes and published compromise checks, but warns that a successful attack leaves nothing in the logs.
What happened
On 10 November 2026 Vates, the French company behind the XCP-ng hypervisor and its Xen Orchestra management platform, published security advisory VSA-2026-062. It rates the flaw as critical and confirms that a threat actor is already exploiting it. The issue affects both Xen Orchestra installed from source and the packaged Xen Orchestra Appliance (XOA). At the time of writing there is no CVE identifier, and Vates lists the CVSS score as not yet available.
Credit for the discovery goes to TDC NET Security researchers Filip Magic and Christoffer Olsen. According to Vates, builds earlier than Xen Orchestra 6.9.2 on the stable channel and 6.10.1 on the latest channel are vulnerable, and those releases contain the fix. Some early press coverage, including BleepingComputer and The Hacker News, cited 6.9.1 and 6.10.0 as fixed, though the xo-server builds they named (5.211.2 and 5.213.1) match the advisory. The vendor advisory is the authoritative reference, so administrators should treat anything older than 6.9.2 or 6.10.1 as exposed.
Vates has not said when the attacks began, and it remains unclear whether the flaw was abused before the vendor knew about it. The Hacker News reports that one IP address linked to the campaign has been flagged on VirusTotal as RedLine Stealer command-and-control infrastructure; that detail comes from a single outlet and has not been confirmed by Vates.
The technical picture
Xen Orchestra exposes a REST API that authenticates callers with a token carried in a cookie. The vulnerability is a type-confusion problem in that check. The code expects the token to be a simple text string but never enforces it. When a malformed value arrives, the lookup that should match one specific token instead behaves like an unfiltered search and hands back the first valid token it holds. If that token has not expired, the server treats the caller as its owner.
The attacker needs no stolen secret: an installation in regular use will usually hold a live token, and the intruder simply inherits its owner’s identity. From there, Vates says, an authenticated API route can be used to obtain reusable login tokens, giving the intruder persistent access rather than a one-off session.
The consequences are severe. Vates states that an adversary gains Admin privilege, opening the door to running code across managed pools and seizing XCP-ng hosts with root rights. Xen Orchestra also stores the credentials it needs to do its job: backup remotes on NFS, SMB, S3 or Azure, proxy settings, pool secrets, root accounts, user accounts, one-time password secrets and mail server configuration. Vates says it cannot rule out configuration theft or credential harvesting.
The vendor has published indicators tied to the campaign it has observed. These include traffic to an onion address over Tor and a specific IP address, virtual machines configured to write their serial console output to a file, a VM named “pivot2”, and unexpected cron entries and marker files on hosts, including entries under /etc/cron.d with “zz-ustar” in the name. Crucially, the advisory notes that exploitation produces no log record of the unauthenticated access, so the attack can only be spotted by examining HTTP traffic itself.
Why it matters for UK organisations
XCP-ng and Xen Orchestra are open-source and modestly priced, which makes them a natural fit for hosting providers, managed service providers, universities, councils and mid-sized firms that want enterprise virtualisation without enterprise licence fees. Many UK organisations have been reassessing their hypervisor platforms over the past two years, and XCP-ng is one of the options regularly shortlisted.
The management console is the single most privileged system in a virtualised environment. Whoever controls it controls every guest beneath it: domain controllers, file servers, finance databases and, very often, the backup jobs meant to rescue you. Ransomware crews have spent years targeting hypervisor management planes for exactly this reason, because encrypting at the host layer takes out hundreds of servers at once and backup credentials stored in the console help them close the recovery route.
There is a supply chain angle too: one exposed console at a UK MSP running multi-tenant XCP-ng could become a route into many customers. Buyers of hosted infrastructure should ask providers this week whether they use Xen Orchestra and whether it is patched.
Expert view
This is a textbook input-validation failure, and the sort that slips past code review because it looks harmless. A lookup that treats “nothing specified” as “match everything” is a pattern I have met in other authentication code over the years, and it is always nasty.
What worries me more than the bug is where it lives. When we test virtualised estates, the hypervisor management interface is frequently reachable from far more of the network than it should be, and occasionally from the internet. If an attacker can reach it, a flaw like this turns a foothold into total control.
The absence of logging is the other sting. Many teams will run the checks, find nothing and relax. Vates itself is clear that its indicators cover only one campaign and that a clean result does not prove the host is clean. If your console has been exposed beyond a tightly controlled management network, you should assume it may have been accessed and act accordingly.
What to do now
- Update immediately. Move Xen Orchestra to 6.9.2 (stable) or 6.10.1 (latest), or update XOA through its normal channel. If you built from source, pull the latest code. This maps to the Cyber Essentials security update management control.
- Take the console off the internet. Restrict Xen Orchestra to a dedicated management network or VPN, with firewall rules limiting which hosts can reach it. This is the Cyber Essentials firewall and secure configuration requirement in practice.
- Block the known infrastructure. Deny traffic to and from the IP address and onion service in the Vates advisory, and block Tor egress from hypervisor hosts.
- Hunt for compromise. Run the host checks Vates provides, look for unfamiliar VMs, file-backed serial consoles and unexpected cron or preload entries, and review any proxy or packet captures for malformed authentication cookies.
- Rotate secrets. If there is any sign of access, rotate every credential Xen Orchestra holds, including backup remote, pool, root, user and OTP secrets, in line with Cyber Essentials user access control.
- Rebuild if compromised. Vates recommends a full reinstallation after a confirmed compromise, because cleanup alone cannot guarantee every backdoor has gone. Verify backups are intact and isolated before restoring.
A web application firewall or reverse proxy rule rejecting malformed tokens can buy time, but Vates warns such rules can be evaded with alternative encodings. Treat it as a stopgap, not a fix.
Bottom line
An actively exploited, unauthenticated route to administrator rights on a hypervisor console is about as serious as vulnerabilities get. Patch Xen Orchestra today, lock it behind a management network, and do not take a clean indicator sweep as proof of safety. If the console was exposed, rotate its secrets and be ready to rebuild.
