Vates Says Attackers Are Exploiting a Xen Orchestra Login Bypass Triggered by an Empty Cookie Object, and Its Advisory Changed the Fixed Versions From 6.10.0 and 6.9.1 to 6.10.1 and 6.9.2 Within the Day

Vates, the French company that develops Xen Orchestra, published advisory VSA-2026-062 on Tuesday, November 10, for an authentication bypass in Xen Orchestra (XO), the web-based console used to manage XCP-ng virtualization pools. Vates rates it Critical and says a threat actor is exploiting it; no CVE ID or CVSS score exists yet. BleepingComputer reported it at 16:17 UTC. We read the advisory as first archived and as it stands now, the fix pull request and the pre-fix source in Vates’ public repository, and we checked CISA’s exploited-vulnerabilities feed and the National Vulnerability Database. This is a snapshot from the evening of November 10, between about 19:00 and 20:00 UTC.

Three facts frame it. First, the advisory’s fixed versions changed during the day: its earliest archived copy, from 11:31 UTC, says Xen Orchestra 6.10.0 and 6.9.1 include the fix, while the live copy says builds before 6.10.1 and 6.9.2 are affected. BleepingComputer’s report carries the first pair, yet the project’s changelog dates 6.10.0 and 6.9.1 to October 29 and October 5, the fix was merged on November 10, and Vates’ own pull request names xo-server 5.213.0, the package in 6.10.0, as the unpatched build. Second, the advisory’s bypass is a single cookie value that Vates says leaves no log, and by our reading of the source it also skips two-factor authentication. Third, the fix only validates input: it does not revoke login tokens an attacker may already have taken, and a token lasts 30 days by default.

What Vates says

Vates’ summary is short: “REST cookie parsing turns authenticationToken=j:%7B%7D into {}. REST authentication passes that object to the XO token provider without requiring a string. The token collection treats {} as an unfiltered lookup and returns its first token; the provider authenticates as that token’s owner if it is unexpired. The authenticated /rest/v0/users/me/authentication_tokens route then returns reusable login token IDs.” Its impact line reads “An adversary can bypass authentication and perform actions with ‘Admin’ privilege. Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root.”

The advisory lists the affected products as Xen Orchestra and the Xen Orchestra Appliance (XOA), gives the CVSS 4.0 score as “Not available yet”, and credits Filip Magic and Christoffer Olsen of TDC NET Security. It says the flaw is “actively exploited by a threat actor”. It gives no victim count, no date for the first exploitation and no name for the actor.

Which build is fixed

The advisory carries no revision note: its Published and Updated columns both read 2026-11-10. We compared the earliest copy in the Internet Archive, captured at 11:31:51 UTC, with the page as we read it at 19:19 UTC.

Both copies of the advisory name the same fixed packages: xo-server 5.213.1 on the latest channel and 5.211.2 on the stable channel. The product numbers are what differ. Read on its own terms, the first copy contradicts itself, because it calls xo-server before 5.213.1 affected and 6.10.0 shipped xo-server 5.213.0. The advisory does not say whether the first text was a slip or a change of release plan. BleepingComputer’s sentence mixes the two sets: its product numbers belong to the October releases and its package numbers to the fix.

For that reason we would compare the package, not the product number: the fixed xo-server is 5.213.1 on the latest channel and 5.211.2 on stable. We could not confirm the 6.10.1 and 6.9.2 releases from public records. The changelog has no such heading yet, and the pull request’s own checklist says “Not run: stable backport validation.” For installs from source, Vates says to “update to the latest master”, which has included the fix since merge commit 50166fe3a at 08:29:37 UTC.

How the bypass works

XO’s REST layer reads the login token from a cookie named authenticationToken or token, passes it to the token provider and then insists the user is an administrator. Express’s cookie-parser, which XO registers for the whole web app, treats a cookie value that starts with j: as JSON, so j:{} arrives as an empty object rather than a string. The provider’s guard, if (!tokenId), lets that through, because an object is always truthy. The lookup then runs this._tokens.first(properties ?? id). XO’s collection class uses an object argument as the filter, and an empty filter matches every token, so first returns the first token in the list.

// packages/xo-server/src/xo-mixins/rest-api.mjs, before the fix
async #authenticateUser(req) {
  const { cookies, ip } = req
  const token = cookies.authenticationToken ?? cookies.token

  if (!token) {
    throw invalidCredentials()
  }

  const { user } = await this.#app.authenticateUser({ token }, { ip })

  if (user.permission !== 'admin') {
    throw unauthorized()
  }

  return user
}

// packages/xo-server/src/xo-mixins/authentication.mjs, before the fix
this.registerAuthenticationProvider(async ({ token: tokenId }, { ip } = {}) => {
  if (!tokenId) {
    return
  }

  try {
    const token = await app.getAuthenticationToken(tokenId)

    let { last_uses = {} } = token
    last_uses[ip] = { timestamp: Date.now() }
    // ... (lines omitted)
    await this._tokens.update(token)

    return { bypassOtp: true, expiration: token.expiration, userId: token.user_id }
  } catch (error) {}
})

async _getAuthenticationToken(id, properties) {
  const token = await this._tokens.first(properties ?? id)
  if (token !== undefined) {
    if (token.expiration > Date.now()) {
      return token
    }

    this._tokens.remove(id)::ignoreErrors()
  }
}

async getAuthenticationToken(properties) {
  const id = typeof properties === 'string' ? properties : properties.id

On the REST route the cookie therefore works only when the first token belongs to an administrator, which fits Vates’ “Admin” wording. The empty filter reads token IDs from a Redis set (sMembers) with no promised order, and we could not tell which owner an attacker gets on a real instance. A token sign-in also skips the one-time-password check: the authentication code carries the comment “some authentication providers bypass OTP (e.g. token)”, so two-factor authentication on the owner’s account would not have stopped the cookie. And a success leaves no entry in XO’s task log: authentication creates a task that is cleared on success (“only keep trace of failed attempts”), which fits Vates’ line that “there is no log to detect unauthenticated access”.

The fix, pull request 10748 (four files, 266 lines added and 5 removed), rejects anything that is not a non-empty string before the collection is queried. Its description says it will “Build the lookup query from validated fields only, so extra keys from caller-supplied objects never reach the collection.”

// packages/xo-server/src/xo-mixins/authentication.mjs, after the fix (pull request 10748)
const isNonEmptyString = value => typeof value === 'string' && value.length !== 0

async _getAuthenticationToken(id, userId) {
  if (!isNonEmptyString(id) || (userId !== undefined && !isNonEmptyString(userId))) {
    return
  }

  // build the query from validated fields only, never forward caller-supplied objects
  const token = await this._tokens.first(userId === undefined ? id : { id, user_id: userId })

The pull request also names the commit that introduced the bug: 115bc8fa0a65, dated June 7, 2022 and titled “feat(xo-server): authentication tokens can have a description”. That puts the lookup in the code for more than four years, and the commit’s diff shows that the previous version of the function already handed its argument straight to first, so the pattern may be older than the commit the pull request names. The advisory gives no lower bound for affected versions, and which releases could be reached through the REST cookie depends on when that route began reading cookies, which we did not trace.

The pull request covers more than the cookie. Its description says non-string and empty token IDs are now rejected on “the REST API, /signin and JSON-RPC session.signIn”. In the pre-fix source the sign-in page takes a token from its query string, and session.signIn passes its credentials object to the same providers. That method declares no parameter schema, unlike its deprecated alias signInWithToken, which requires token to be a string. We did not test whether those routes were exploitable before the fix, and the advisory describes only the cookie.

What the fix does not do

The pull request changes validation and adds tests. It does not delete, rotate or shorten any token. Its one changelog line, under Security, reads “Fix authentication token validation”. The advisory’s clean-up advice says to “Rotate all passwords and secrets in Vates VMS if Xen Orchestra has been compromised” and lists proxy and backup-remote credentials, the root account and pool secret, user accounts, OTP secrets and mail-server passwords. It does not mention authentication tokens.

By our reading that leaves a gap. The REST route the advisory names returns “reusable login token IDs”, a token ID is itself the credential (the cookie carries it), and the shipped configuration gives a new token 30 days with a ceiling of half a year (defaultTokenValidity = '30 days' and maxTokenValidity = '0.5 year' in config.toml). An attacker who listed an administrator’s tokens before the update can keep signing in with them after it, with the one-time-password check skipped, until they expire or are deleted.

The XO 5 interface source shows where to look. A user’s page lists each authentication token with its description, a “Last use” column (a time and an address) and its expiration, and offers a delete action and a “Delete selected authentication tokens” action. The token provider stamps the caller’s address and the time into last_uses, keeping the ten most recent addresses, every time a token signs in. By our reading, a bypass that lands on an administrator’s token should therefore show up there as an address you do not recognize, or as your reverse proxy’s address at a time nobody signed in. That is a lead, not proof: we did not test it on a live instance, a proxy can hide the real address, and an attacker with administrator rights can delete the evidence.

Indicators and checks Vates published

Vates warns that its detection methods “only cover this specific campaign” and that “The absence of these IoCs alone is not sufficient to conclude that no compromise has occurred.” For a confirmed compromise it says “a full reinstallation is recommended as cleanup alone cannot guarantee the removal of all backdoors left by the attacker.”

Vates gives three commands for the hosts. The advisory does not explain what the serial-port setting is used for in the attack, and we do not know.

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*

We have no XCP-ng host here, so we tested only the patterns. Over a made-up file laid out the way xe prints a VM list, the first command printed the pivot2 name line and its platform line and skipped the VMs with hvm_serial: none or no serial setting. Over a gzipped log and a plain log with one matching line between them, the second command printed the matching line with the name of the compressed file. Neither test says anything about the output on a real pool.

The live advisory tells admins to block eight addresses. The first copy listed one, and it described the actor as operating from that address, where the live text says the actor was operating from it initially. We looked the eight up in the registries (RDAP) and in RIPEstat.

The eight addresses come from eight separate address blocks run by seven network operators, so blocking by network is not practical and the advisory asks for per-address rules. A registry record says who holds an address block, not who rents the server, and we draw no conclusion about the companies listed.

The advisory also suggests a WAF or reverse-proxy rule to “Block the empty token”, and it adds “be cautious with regex, the rule can be bypassed using other formats”. The source shows why. The REST route accepts the token from either of two cookie names, and Vates’ pull request lists the sign-in page and the JSON-RPC sign-in call, which take a token from the query string and from a request body instead of a cookie. A rule keyed on one cookie name covers none of them. We would treat such a rule as a stopgap until the update is in.

What we could not establish

• Whether a CVE ID is coming. The advisory gives the CVSS 4.0 score as “Not available yet”, and NVD’s keyword search for Xen Orchestra returns three records, none for this flaw: CVE-2021-36383 and two October CVEs, CVE-2026-110111 and CVE-2026-113610, which describe other bugs in builds before 6.9.0 and involve authenticated users.
• Whether CISA lists it. The catalog we read (2026.11.10, released at 19:03 UTC) has no entry naming Xen Orchestra, Vates or XCP-ng.
• How many instances were hit, since when, and by whom. The advisory says “a threat actor” and gives no date, count or name.
• Which token comes first on a given instance, and whether the last-use column shows the attacker. We did not run XO.
• Whether the sign-in page and the JSON-RPC sign-in call were exploitable before the fix.
• Whether 6.10.1 and 6.9.2 are on the update channels. We did not check an appliance, and the public changelog does not list them yet.

What to do

These steps are ours, drawn from the advisory and the source; the first and third follow Vates’ own advice.

1. Keep XO off the internet and reachable only from a management network, as Vates recommends.
2. Update, then confirm that the installed xo-server package is at least 5.213.1 on the latest channel or 5.211.2 on stable, whatever product number the update shows. On a source install, update to a master that includes commit 50166fe3a.
3. Hunt with Vates’ indicators on XO and on every XCP-ng host, and block the eight addresses and Tor traffic as the advisory says. If anything matches, Vates recommends a full reinstallation.
4. On any instance that was reachable while unpatched, delete the authentication tokens of every administrator after the update (and of other users if you can), and check their last-use addresses first. Rotate the secrets in Vates’ list if any indicator matched.
5. Treat a WAF rule on the cookie as a stopgap, for the reasons above.

The checks we ran

We sent nothing to any Xen Orchestra instance, contacted none of the listed addresses and ran no exploit. We read the live advisory and the Internet Archive’s capture of it (one capture, 11:31:51 UTC, in its index), the fix pull request and the commit it blames through GitHub’s API, and the source at the pull request’s base commit 724402733b. We checked the cookie-parser documentation, CISA’s feed and NVD, and looked up the eight addresses. The script below repeats the version, changelog, pull request, CISA and NVD checks; it uses only the standard library and sends read-only requests. Its output is from 19:22 UTC.

# xo_check.py
# Compares the first archived copy of Vates advisory VSA-2026-062 with the live copy,
# reads the project changelog and the fix pull request, and checks CISA KEV and NVD.
# Standard library only. Nothing here contacts a Xen Orchestra server.
import html
import json
import re
import urllib.parse
import urllib.request

UA = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/130.0.0.0 Safari/537.36"}


def get(url):
    req = urllib.request.Request(url, headers=UA)
    with urllib.request.urlopen(req, timeout=90) as resp:
        return resp.read().decode("utf-8", "replace")


def page_text(raw):
    raw = re.sub(r"(?is)<(script|style).*?</\1>", " ", raw)
    raw = re.sub(r"(?s)<[^>]+>", " ", raw)
    return re.sub(r"\s+", " ", html.unescape(raw))


ADVISORY = "https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/"
FIRST = "https://web.archive.org/web/20261110113151id_/" + ADVISORY

for label, url in (("first archived copy (11:31:51 UTC)", FIRST), ("live copy", ADVISORY)):
    text = page_text(get(url))
    affected = re.search(r"Affected Versions\W+(.+?) : Affected", text)
    fixed = re.search(r"As of 2026-11-10, (.+?) has been updated and includes the fix", text)
    block = text.count("Add a filter rule for ingress and egress traffic to block")
    ips = re.findall(r"\b\d{1,3}(?:\.\d{1,3}){3}\b(?!:)", text.split("Add a filter rule")[1].split("Block Tor")[0])
    print(label)
    print("  affected:", affected.group(1) if affected else None)
    print("  fixed   :", fixed.group(1) if fixed else None)
    print("  addresses in the block list:", len(ips) if block else 0)

changelog = get("https://raw.githubusercontent.com/vatesfr/xen-orchestra/master/CHANGELOG.md")
heads = re.findall(r"^## \*\*(\d+\.\d+\.\d+)\*\* \((\d{4}-\d{2}-\d{2})\)", changelog, flags=re.M)
print("newest changelog headings:", heads[:3])
for version in ("6.10.0", "6.9.1"):
    start = changelog.index("## **%s**" % version)
    end = changelog.index("\n## **", start + 5)
    section = changelog[start:end]
    packages = re.findall(r"^- (xo-server [\d.]+)", section[section.index("### Released packages"):], flags=re.M)
    print(version, "released", packages)

pr = json.loads(get("https://api.github.com/repos/vatesfr/xen-orchestra/pulls/10748"))
print("PR 10748 opened", pr["created_at"], "merged", pr["merged_at"])

feed = json.loads(get("https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"))
hits = [v["cveID"] for v in feed["vulnerabilities"] if re.search(r"xen orchestra|vates|xcp-ng", json.dumps(v), re.I)]
print("KEV catalog", feed["catalogVersion"], "entries naming Xen Orchestra, Vates or XCP-ng:", hits or "none")

query = urllib.parse.urlencode({"keywordSearch": "Xen Orchestra"})
nvd = json.loads(get("https://services.nvd.nist.gov/rest/json/cves/2.0?" + query))
print("NVD keyword search, Xen Orchestra:", nvd["totalResults"], "records")
for item in nvd["vulnerabilities"]:
    cve = item["cve"]
    print(" ", cve["id"], cve["published"][:10], cve["descriptions"][0]["value"][:70])

first archived copy (11:31:51 UTC)
  affected: xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest)
  fixed   : Xen Orchestra version 6.10.0 and Xen Orchestra 6.9.1
  addresses in the block list: 1
live copy
  affected: Xen Orchestra before 6.9.2 (stable) and 6.10.1 (latest)
  fixed   : Xen Orchestra version 6.10.1 and Xen Orchestra 6.9.2
  addresses in the block list: 8
newest changelog headings: [('6.10.0', '2026-10-29'), ('6.9.1', '2026-10-05'), ('6.9.0', '2026-09-30')]
6.10.0 released ['xo-server 5.213.0']
6.9.1 released ['xo-server 5.211.1']
PR 10748 opened 2026-11-10T08:13:17Z merged 2026-11-10T08:29:37Z
KEV catalog 2026.11.10 entries naming Xen Orchestra, Vates or XCP-ng: none
NVD keyword search, Xen Orchestra: 3 records
  CVE-2021-36383 2021-07-12 Xen Orchestra (with xo-web through 5.80.0 and xo-server through 5.84.0
  CVE-2026-110111 2026-10-13 Xen Orchestra before 6.9.0 contains an improper access control vulnera
  CVE-2026-113610 2026-10-20 Xen Orchestra before 6.9.0 contains an authorization bypass vulnerabil

Sources

• Vates, VSA-2026-062: Empty-object login token (live copy read at 19:19 UTC) and the Internet Archive capture of 11:31:51 UTC
• BleepingComputer, Lawrence Abrams, November 10, 2026
• Xen Orchestra pull request 10748, fix(xo-server): validate authentication token IDs, and the commit it names as the origin
• Xen Orchestra CHANGELOG.md (releases 6.10.0 and 6.9.1)
• Xen Orchestra source at commit 724402733b: rest-api.mjs, authentication.mjs, collection.mjs, redis.mjs, session.mjs, config.toml and the XO 5 user page
• expressjs/cookie-parser README (JSON cookies)
• CISA Known Exploited Vulnerabilities feed (catalog 2026.11.10) and the NVD records named above
• Registry data for the eight addresses from RDAP and RIPEstat