Research

Xen Orchestra Has a Login Bypass That Attackers Are Already Using: One Crafted Cookie Logs Them In as an Admin. The Fixed Versions Are 6.9.2 and 6.10.1, Not the Ones the Press Printed

Patrick Duggan · · 4 min read

Xen Orchestra Has a Login Bypass That Attackers Are Already Using: One Crafted Cookie Logs Them In as an Admin. The Fixed Versions Are 6.9.2 and 6.10.1, Not the Ones the Press Printed
Facts for the Xen Orchestra authentication bypass, Vates advisory VSA-2026-062, November 10, 2026. A crafted cookie logs an attacker in as an admin and it is being exploited. Fixed versions are 6.9.2 and 6.10.1, not 6.9.1 and 6.10.0. Update, keep it off the internet, block the published addresses.

If you run Xen Orchestra, update it today to 6.9.2 (stable) or 6.10.1 (latest), and take it off the internet until you have. Vates, the vendor, confirmed on November 10 that an unauthenticated login bypass is being exploited. A crafted cookie makes the server log the attacker in as the owner of an existing login token, which gives them Admin on your virtualization management. Two news reports give different fixed versions from the vendor's own advisory. Use the vendor's.

What has been reported

The primary source is Vates advisory VSA-2026-062, published and updated November 10, which we had read in full for us by an agent. The Hacker News and BleepingComputer (both November 10) match it except on version numbers. The fix is also public as a code change on GitHub (merged November 10).

  • The versions, where sources disagree: the advisory lists Xen Orchestra before 6.9.2 (stable) and before 6.10.1 (latest) as affected, and the Xen Orchestra Appliance too. Both news reports say 6.9.1 and 6.10.0 are the fixed builds. Per the advisory those are the affected ones. For the xo-server package, all sources agree on 5.211.2 (stable) and 5.213.1 (latest).
  • The mechanism, per Vates: the REST interface parses a cookie named authenticationToken and, for an empty object value, passes it to the token lookup without checking that it is a string. The lookup treats the empty object as "no filter" and returns the first token it holds. The server then authenticates the request as that token's owner, if the token has not expired. Vates adds that the same route then returns reusable login token IDs.
  • What it gives an attacker: "bypass authentication and perform actions with 'Admin' privilege," per Vates. The reports describe code execution on managed pools and takeover of the underlying XCP-ng hosts.
  • Detection: Vates says there is no log entry for the unauthenticated access, so detection has to come from HTTP monitoring in front of Xen Orchestra. It publishes two cookie patterns to look for: authenticationToken set to j:%7B%7D, or to j:{}.
  • Exploitation: Vates confirmed active exploitation. No source gives a first-seen date, and The Hacker News says it is unclear whether this was a zero-day. No CVE has been assigned. No public exploit code is mentioned in anything we read; the advisory and the fix describe the mechanism in detail.
  • Indicators Vates publishes: a command-and-control address 91.211.251.112 (port 8001), a Tor address on port 3333, and seven more addresses to block: 193.148.56.72, 37.221.208.216, 45.66.35.11, 64.65.0.120, 64.65.62.160, 89.47.51.90 and 92.60.37.247. On compromised systems: cron files named zz-ustar and zz-ustar2 under /etc/cron.d, files named .ustar5 and .ustar6 at the filesystem root, a running VM named pivot2, and VMs with the setting hvm_serial: file. Vates says these are tied to this one campaign and that missing indicators do not prove you are clean.

What it means

A management console for virtual machines is the place where one login becomes every server underneath it. This bug needs no password, no user and no second step, and it leaves no authentication log. The practical danger is the gap between "I am on 6.10.0, the news says that is fixed" and the vendor saying it is not. A reader who stopped at the headline and checked their version against the press would believe they were safe.

What to do

  1. Update to Xen Orchestra 6.9.2 or 6.10.1, or xo-server 5.211.2 or 5.213.1. If you built from source, update to the latest master. Do not stop at 6.9.1 or 6.10.0.
  2. Until patched, keep Xen Orchestra off the internet and reachable only from a dedicated management network.
  3. Block the addresses above in both directions, and the Tor address on egress.
  4. Add a rule in your reverse proxy or web application firewall for the empty-token cookie. Vates warns that a simple pattern can be bypassed with other formats, so treat it as a stopgap.
  5. Check hosts for compromise. Vates gives three checks: list VMs whose platform setting includes hvm_serial: file, search the xensource logs for "-serial file:", and look for /etc/ld.so.preload, the .ustar files and the zz-ustar cron files.
  6. If you suspect compromise, rotate every secret Xen Orchestra holds: the proxy, backup remotes, root account, pool secret, user accounts, one-time-password secrets and mail server passwords. If compromise is confirmed, Vates recommends a full reinstall, because cleanup cannot guarantee the backdoors are gone.

What is not known

When exploitation started and how many installations were taken. Which versions first contained the bug: Vates says only "before" the fixed builds, and the GitHub change names the commit that introduced it but not the release. Who the attacker is. Whether the C2 address is a known stealer server: The Hacker News says VirusTotal flags it, and we did not verify that.

How we know, and how we checked

We read the Vates advisory, the GitHub change that fixes it, and both news reports, through an agent. We did not test the bug or any host. We ran our edge check over the window since October 10 for the REST path and the token route: no match among 190,143 blocked requests, 40,742 honeypot decoy hits and 1,009 origin captures. That is a measurement of those three sources only. We run no Xen Orchestra, and no decoy for it, so it says nothing about whether the attack is widespread. We added the eight IP addresses Vates publishes to our indicator feed, credited to Vates. We did not add the Tor address or the file names. A search of our corpus found our November 4 post on the separate Xen hypervisor flaws (XSA-523) and no earlier post on Xen Orchestra.

Sources

Vates, security advisory VSA-2026-062, "Xen Orchestra authentication bypass," November 10, 2026. Vates / xen-orchestra GitHub pull request 10748, "fix(xo-server): validate authentication token IDs," merged November 10, 2026. BleepingComputer, "Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers," Lawrence Abrams, November 10, 2026. The Hacker News, "Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access," November 10, 2026.

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com