Xen Orchestra Authentication Bypass Exploited: Patch XCP-ng Management Servers and Check for Compromise

Many Windows shops run Windows Server guests, domain controllers and SQL workloads on XCP-ng. Whoever controls the hypervisor management plane controls every VM beneath it. This is an infrastructure story that lands squarely on Windows admins' desks.

What is affected​

Xen Orchestra (XO) is the web-based management layer for XCP-ng. It handles VMs, hosts, pools and backups. Vates says the flaw affects both Xen Orchestra and the Xen Orchestra Appliance (XOA). The vulnerable component is xo-server.

• Severity: Vates rates it Critical.
• CVE and CVSS: the advisory shows the CVSS 4.0 score as "Not available yet". No CVE identifier has been reported at the time of writing.
• Impact: in Vates's words, an adversary can bypass authentication and act with Admin privilege. The advisory adds that this can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root.

How the bypass works​

XO's REST API expects a valid token in a cookie named authenticationToken. The XCP-ng documentation shows this as the standard way to authenticate REST requests. A valid authentication token should be attached as a cookie to all HTTP requests, and invalid tokens should get a 401.

The bug breaks that contract. Per the Vates advisory:

1. The REST cookie parser turns authenticationToken=j:%7B%7D into an empty JSON object, {}.
2. REST authentication hands that object to the XO token provider without checking that it is a string.
3. The token collection treats {} as an unfiltered lookup and returns its first token.
4. If that token has not expired, the provider authenticates the caller as the token's owner.
5. The authenticated /rest/v0/users/me/authentication_tokens route then returns reusable login token IDs. XO's own API documentation describes creating authentication tokens through that same route. The attacker therefore gets durable credentials, not just a one-off session.

The qualifier matters. The attacker does not guess a token. The empty object makes the lookup match anything, so the server returns a real token. Access depends on that token being unexpired. In practice, an active installation will almost always have one.

Fixed versions​

Vates ships fixes on both release channels as of November 10, 2026:

The advisory's affected-versions line is oddly worded. It says "xo-server before 5.213.1 and 5.213.2" in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest). Treat any build older than the fixed releases above as vulnerable, and check your own version against the table. XOA is listed as affected as well, so use the appliance's normal update path.

Indicators of compromise​

Vates ties the following to the known campaign.

Attacker infrastructure

• 91.211.251.112:8001
• ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333, reached over Tor

On the wire

• HTTP requests containing authenticationToken=j:%7B%7D or authenticationToken=j:{}

In the environment

• A VM named pivot2
• VMs whose platform settings include hvm_serial: file
• Files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 and /.ustar6

Vates supplies these checks for XCP-ng hosts:

xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'
zgrep -- '-serial file:' /var/log/xensource.log*
ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

The first command lists VMs that use a file-backed serial port. The second searches the Xen logs, including rotated, compressed ones, for the same -serial file: setting. The third looks for the named cron and marker files, plus /etc/ld.so.preload. Vates includes that last path in the command but does not explain why. An unexpected entry there is worth investigating on any host.

The detection catch​

Vates warns that a successful exploit leaves no log entry showing unauthenticated access. The only way to see the cookie is to watch HTTP traffic itself, for example with tcpdump or Wireshark. If your XO sits behind a TLS-terminating reverse proxy, that proxy is the natural place to inspect requests.

The indicators also cover only the campaign Vates has seen. The advisory says other actors may use different infrastructure and techniques. It also says a clean result from these checks does not prove nothing happened.

What to do now​

1. Patch. Move to 6.10.0 (latest) or 6.9.1 (stable). Vates strongly recommends updating as soon as possible.
2. Take XO off the internet. Vates advises against exposing it publicly and recommends a dedicated management network.
3. Cut the command channel. Block ingress and egress traffic to 91.211.251.112. Block Tor traffic so the onion address can't be reached.
4. Add a stopgap WAF or reverse-proxy rule matching authenticationToken=j:{} and authenticationToken=j:%7B%7D. Vates cautions that regex rules can be bypassed with other encodings. Treat this as a bandage, not a fix.
5. Hunt. Run the host checks above and search captured HTTP traffic for the cookie patterns.
6. If you suspect compromise, rotate secrets. Vates says configuration exfiltration and credential harvesting can't be ruled out. Its examples are proxy, backup, S3, root-account and user-account credentials.

Analysis​

The bug is small but its blast radius is large. Authentication code that accepts a non-string where a string belongs is a classic failure. Here a filter-style lookup quietly turned "nothing specified" into "match everything." The management console sits above every guest, so one parsing flaw hands over the whole estate. That is why Vates pairs "Admin" with "root on the node."

The Windows angle is practical. A root-level takeover of a host exposes the disks and memory of every guest on it, including domain controllers, file servers and SQL Server instances. Backup credentials stored in XO are especially attractive. If your recovery path runs through the same console, a compromise can undermine your ability to restore as well.

One caveat on sourcing. The indicator list reflects what Vates observed in one campaign. Details such as the ustar file names are useful for a quick sweep but are easy for a different operator to change. Patch first, then hunt. Don't hunt in place of patching.

If your XO instance has ever been reachable from the internet, assume exposure until you have proof otherwise. Update it, review your traffic captures, and rotate the credentials it holds.