Xen Orchestra VSA-2026-062: critical login bypass exploited, update to 6.9.1 or 6.10.0

Vates, the company behind the open-source Xen Orchestra (XO) management console for XCP-ng and Xen virtualization, published advisory VSA-2026-062 on 10 November 2026. It describes a critical authentication bypass in the XO server that lets a remote attacker log in as an existing user without any credentials, and Vates says the flaw is being actively exploited. The bug sits in the piece of software that holds the keys to every virtual machine (VM) host it manages, so anyone running XO should treat this as an emergency update.

Key points

• Vates advisory VSA-2026-062 (published 2026-11-10) rates the Xen Orchestra authentication bypass "Critical" and states it is being actively exploited; no CVE ID or CVSS score had been assigned when it was published.
• A crafted cookie, authenticationToken=j:%7B%7D, is parsed into an empty object that the login flow accepts and that matches the first stored token, so the attacker is signed in as that token's owner.
• Fixed versions: Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest), which ship xo-server 5.211.2 and 5.213.1.
• The flaw was reported by Filip Magic and Christoffer Olsen of TDC NET Security, per Vates.
• Vates says exploitation leaves no log identifiers, so detection relies on HTTP monitoring and on artefacts left on XCP-ng hosts.

What to do

Who is affected: Xen Orchestra built from source and the Xen Orchestra Appliance (XOA), on versions before the fixed releases above. The advisory's wording on the exact affected xo-server range is ambiguous, so do not try to work out whether your build is "just outside" it: compare your version to the fixed ones.

Fix: update to Xen Orchestra 6.9.1 on the stable channel or 6.10.0 on the latest channel (xo-server 5.211.2 or 5.213.1). The code change is public: Vates merged pull request #10748, "validate authentication token IDs", into the master branch of the xen-orchestra repository on 10 November.

If you cannot update at once, Vates recommends these steps:

1. Do not expose Xen Orchestra to the internet; keep it on a dedicated management network.
2. Block the attacker address 91.211.251.112 and Tor traffic, including to the onion address named in the advisory, in both ingress and egress rules.
3. Block the empty-token patterns (authenticationToken=j:%7B%7D and authenticationToken=j:{}) in a web application firewall or reverse proxy. Vates warns that regex rules can be bypassed with other formats, so this is a stopgap, not a fix.

Check whether you were hit. Vates lists these indicators from the campaign it has seen:

• In Xen Orchestra, a VM named pivot2 among the running VMs.
• On XCP-ng hosts, VMs configured with hvm_serial: file. Vates suggests xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file' and zgrep -- '-serial file:' /var/log/xensource.log*.
• Files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5, /.ustar6 and /etc/ld.so.preload (check them with ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*).
• Outbound connections to 91.211.251.112 on port 8001, or to the onion address on port 3333.
• Requests in web or proxy logs that contain the empty-token cookie.

Vates stresses that the absence of these indicators does not prove you were not compromised, and that they describe this campaign only; another attacker could behave differently. If you suspect compromise, rotate every password and secret that the virtualization environment uses: proxy, backup, S3, root and user accounts.

What happened

According to the advisory, the problem is a chain of three small decisions in how XO handles login tokens. First, the REST layer parses the cookie authenticationToken=j:%7B%7D (the URL-encoded form of j:{}) into an empty JavaScript object. Second, the authentication flow accepts that object without checking that a token is a string. Third, the token lookup treats the empty object as "no filter" and returns the first token in the collection. If that token has not expired, the requester is authenticated as its owner. From there the attacker can reach an authenticated route that returns reusable login token IDs.

Vates says an attacker who gets in can act with administrator privileges, which can lead to arbitrary code execution on the pools XO manages and, ultimately, to taking over an XCP-ng node as root. BleepingComputer, which reported the advisory the same day, quotes Vates confirming active exploitation and lists the same indicators of compromise.

The fix is correspondingly small. The pull request description says it will "reject non-string and empty authentication token IDs before token collection lookups", builds the lookup query only from validated fields, and keeps valid string tokens and the compound { id, user_id } lookups working. The author reports a successful xo-server build, 127 focused authentication and REST tests and 614 xo-server tests passing, and manual checks on a disposable Xen Orchestra Appliance showing that non-string and empty token IDs are now rejected on the REST API, on /signin and on the JSON-RPC session.signIn method. The pull request links the bug to an earlier commit (115bc8f) and to an internal issue, XO-3331. Two reviewers approved it.

Background

Xen Orchestra is the web console and API used to manage XCP-ng and Xen pools: it starts and stops VMs, handles backups, and holds credentials for hosts, storage and backup targets. That makes it a high-value target: one compromised XO instance is a path to every host it manages, which is why Vates's first mitigation is to keep it off the internet.

This is not the first XO security fix this autumn. Public vulnerability databases list two other flaws fixed in Xen Orchestra 6.9.0: CVE-2026-113610, a medium-severity (CVSS 5.3) authorization bypass in the user.set API that lets a low-privileged user change other users' settings, including deleting a TOTP secret to switch off two-factor authentication, and CVE-2026-110111, a CVSS 7.5 privilege escalation through the ESXi import methods. Those require an authenticated account; the new bug does not. None of those entries mentions exploitation, according to the databases we checked.

Separately, the hypervisor layer had its own critical update this month. Vates published VSA-2026-055 for the Xen grant-copy flaws tracked as XSA-523 (CVE-2026-102703 and CVE-2026-102704), which let a malicious guest read and write other domains' memory, and XCP-ng shipped fixes in its November 2026 update. That is a different bug in a different component; patching one does not cover the other.

How it works

The class of bug here is a common one in JavaScript services: input that is supposed to be a string arrives as an object. A cookie format that accepts a j: prefix followed by JSON is convenient, but it means the value is no longer guaranteed to be text. When that value is then passed straight into a database-style query, an empty object means "match anything" rather than "match nothing". The fix, validating that the token ID is a non-empty string before it reaches the lookup, is the standard remedy, and it is why the advisory's WAF advice carries the warning that pattern-matching on the cookie text can be evaded: the real defect is in the validation, not in one particular string.

What it means

For anyone running XO, the practical exposure depends on reachability. An instance reachable only from a management VLAN is much harder to attack than one published to the internet, but the advisory's note that exploitation leaves no log identifiers means you cannot rely on your own logs to say you were fine. Treat any XO that was reachable from untrusted networks before the update as possibly compromised and check the indicators above.

For the wider XCP-ng community the incident repeats an old lesson about management planes: the console that controls your hypervisors deserves the same network isolation as the hypervisors themselves. It also shows how fast the gap between a fix and an exploit can be. The code change, the advisory and the exploitation report all date from the same day, so there was little time between public disclosure and attackers using it, although the sources do not say when exploitation began.

What we don't know yet

• When exploitation started and how many instances were hit. Neither Vates nor BleepingComputer gives a start date or a count.
• A CVE ID and CVSS score. None had been assigned when the advisory was published; we will update this article if one appears.
• The exact affected range. The advisory's description of the xo-server versions is ambiguous, and we have not independently tested older builds.
• Who is behind the campaign. The advisory lists infrastructure but does not name an actor.

What to watch next

Watch the Vates advisory page for an assigned CVE, a CVSS 4.0 score and additional indicators, and for any change to the affected-version wording. Watch the XCP-ng and Xen Orchestra release notes for follow-up fixes. If you operate XO for customers, check whether your monitoring can see inbound HTTP cookies, since Vates says that is the only dependable way to spot the exploit attempt.

Sources

• Vates advisory VSA-2026-062: Empty-object login token (primary)
• BleepingComputer: Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers
• vatesfr/xen-orchestra pull request #10748: validate authentication token IDs
• CVE-2026-113610 record and CVE-2026-110111 record
• Vates VSA-2026-055 (XSA-523)
• XCP-ng November 2026 security and maintenance updates