Vates says Xen Orchestra bypass is exploited, fixed in 5.213.1; its Affected line also lists 5.213.2

The Affected line names 5.213.2; the Resolution never lists it as a fix (derived)

Vates's advisory VSA-2026-062, Empty-object login token is dated 10 November 2026 and covers Xen Orchestra and the Xen Orchestra Appliance. Its warning box says the flaw is "actively exploited by a threat actor". Its Affected Versions line reads: "xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest)". Its Resolution lists xo-server 5.213.1 on the latest channel and 5.211.2 on the stable channel. Count the version numbers in each place and the result is four in the Affected line and four in the Resolution, with three shared (derived). The one only in the Affected line is 5.213.2, a higher number than the 5.213.1 that the Resolution names as the fix. The one only in the Resolution is 5.211.2. The page does not say whether 5.213.2 is a typing slip, a build that stays affected, or something else.

What this does not establish. It does not show which xo-server builds are vulnerable, and it does not show that any build is safe. Treat the Resolution's numbers as the fixed versions Vates names, and treat the Affected line as unreconciled with them. The advisory carries no CVE number and a CVSS 4.0 field that reads "Not available yet". A National Vulnerability Database keyword search for Xen Orchestra, run at 18:24 UTC on 10 November 2026, returned three CVE records, all published before this advisory; none describes a cookie or an empty object (derived from reading their descriptions). The CISA Known Exploited Vulnerabilities catalogue, release 2026.11.09, has no Vates or Xen Orchestra entry; that release is dated 9 November, the day before the advisory, so its silence says only that.

This briefing read the advisory at 18:18 UTC on Tuesday 10 November 2026 and compared it with a copy saved earlier the same day; the text of the two is identical. A page this new can be revised, so anything here that could change within the hour (the version lines, the indicator list, the absence of a CVE) carries that time stamp. Vates has a selling interest in the product it advises on, as its own documentation site shows: the navigation lists "Pricing and licensing", "Pro Support" and "Services and training" as sections. Two researchers at TDC NET Security are credited with the discovery.

What the advisory says happened, in the order it prints it

The Summary is four sentences, and the diagram numbers its clauses as five steps. In Vates's words the cookie value "authenticationToken=j:%7B%7D" is turned by REST cookie parsing into an empty object. REST authentication hands that object to the Xen Orchestra token provider without requiring a string. The token collection treats the empty object as an unfiltered lookup and returns its first token, and the provider authenticates as that token's owner if the token is unexpired. An authenticated route under /rest/v0/users/me then returns reusable login token IDs.

The stated impact is "An adversary can bypass authentication and perform actions with 'Admin' privilege." The page adds that a Xen Orchestra compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root. Read together, the Summary and the Impact leave a question the page does not answer: the login is as the owner of the collection's first token, if that token is unexpired, and the Impact says Admin. The page does not say whose token that is, or whether a first token that belongs to a non-admin user would give less.

Zoom

The fix, as its public pull request describes it. The pull request on Vates's Xen Orchestra repository, number 10748, is titled "fix(xo-server): validate authentication token IDs". Its description says it will "Reject non-string and empty authentication token IDs before token collection lookups." and build the lookup from validated fields only. The page data gives the merge time as 08:29 UTC on 10 November 2026. The pull request names a commit it says introduced the problem; this briefing could not read that commit, because GitHub answered the request with a rate limit, so when the flaw entered the code is not stated here.

Reading the diff on that page (derived): it changes input validation and adds tests. It contains no step that revokes or rotates tokens that already exist. The advisory calls the returned IDs "reusable login token IDs". Whether an ID already handed out stops working after the update, other than by expiring, is not stated by either page. The page's own advice for a compromised instance is to rotate secrets, which the update does not do.

Which version numbers appear where

The table sets out every version number the advisory and the pull request page print, and where each sits. It does not choose between the two lines.

Zoom

Two further limits sit in the pull request's own validation note. It says tests ran on a disposable appliance running xo-server 5.213.0, and lists "Not run: stable backport validation." The advisory lists a stable build, 5.211.2, as a fix. The pull request, at the time its page was read, says the stable backport was not validated by that test run; the page does not say whether it was validated afterwards, by whom, or by anyone outside Vates. The Appliance is listed as "Xen Orchestra Appliance: Affected." with no version at all.

What Vates states, and what it does not

Exploited, but the evidence is thin by design: no log, one campaign

Vates prints campaign indicators and then limits what they mean. The page says: "The absence of these IoCs alone is not sufficient to conclude that no compromise has occurred." It also says the detection methods "only cover this specific campaign" and that exploitation by other actors using different tools and infrastructure "cannot be ruled out". On logging it is plain: "there is no log to detect unauthenticated access". Detection of the request itself is by watching HTTP traffic with tcpdump or Wireshark for the two cookie patterns. Inference, not the page's words: a cookie header is readable only where the connection is not encrypted, so that monitoring has to sit where TLS ends, such as at a reverse proxy; the page does not say where.

Where the page is silent matters to a reader with an exposed instance. It does not say how many instances were reached, does not give a first date for the activity, and does not say whether the pivot2 machine or the cron files are the actor's persistence or something else. It states that configuration exfiltration and credential harvesting cannot be ruled out, and for that reason tells an operator of a compromised instance to rotate every secret Vates VMS uses: proxy, backup, S3, root account and user accounts among them.

Labels that stand in for evidence

Critical, with no score. Vates classifies the impact as Critical by its own severity scale. The score field reads Not available yet. A reader cannot compare it with a CVSS number from anyone else, and no scoring body has attached one. Stable and latest. The Affected line attaches the words stable and latest to Xen Orchestra releases but not to the xo-server numbers, which is where the two lines disagree. Admin. The Impact says Admin; the Summary says the owner of the collection's first token, if unexpired. The label is stronger than the mechanism as printed, and the page does not connect them.

A clean indicator check. Running the three host commands and finding nothing is the check Vates offers, and Vates itself says it is not enough. A clean result means none of this campaign's markers were found. It does not mean the instance was not accessed, because the request leaves no log. A dedicated management network. The advice not to expose Xen Orchestra is sound, and it is a placement, not a control: on this site's reading it limits who can send the cookie and does nothing about a request from inside that network.

Where the sources differ

The only secondary source read is BleepingComputer's article, whose page data dates it 10 November 2026 at 11:17 with a minus five hour offset, which is 16:17 UTC (derived). The pull request merge is 08:29:37 UTC in its own page data, 7 hours 47 minutes earlier (derived). The advisory prints dates only, no times, so the order of the merge, the release and the advisory is not established. The Published date, the Updated date and the Resolution's own date are all 10 November 2026, so the page shows no gap between advisory and fix (derived: 0 days); with no first date for the exploitation, that says nothing about how long instances were exposed. BleepingComputer is a news site; it points to the advisory and this briefing takes no figure from it. Where it says something the advisory does not, the table shows it.

The pull request's test file also names a second cookie name, token, and a percent encoded empty array value, alongside the empty object value. It prints these as cases the fixed code must reject. It does not say any of them worked against the old code, and the advisory's two patterns name neither. That is the concrete reason Vates's caution about a WAF rule holds: a rule that matches only the two printed strings is narrower than what the fix rejects. This is this site's reading of the test file, not a Vates statement.

What to do, in order

Vates's advice comes first, in the order its page prints it, then this site's additions. Vates says to choose the mitigation that suits the deployment and that updating as soon as possible is strongly recommended.

Technical details

Everything below is copied from the Vates advisory or its public pull request. The advisory prints no request sample beyond the cookie value and no payload, and this briefing adds none. Live infrastructure is defanged with square brackets and was never visited, resolved or probed.

The mechanism, as the Summary prints it. One paragraph, copied exactly. A defender reads it to know which parts of the request path to test after patching.

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.

The two cookie patterns. Vates prints these for HTTP monitoring with tcpdump or Wireshark and for a WAF or reverse proxy rule. They belong in a proxy or capture rule where TLS ends, set to alert, with the caution that other formats can bypass them.

authenticationToken=j:%7B%7D
authenticationToken=j:{}

The three commands for XCP-ng hosts. Run on each host. The first lists VMs whose platform has the hvm_serial: file parameter; the second searches the xensource logs for a serial file argument, which the advisory labels a search for the pivot2 VM; the third lists the preload file and the four named paths. Output is for a responder to read; the page does not say what a hit means beyond the labels.

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 artefact names. On Xen Orchestra, a VM named pivot2 among running VMs. On hosts, the files below. A match is a reason to start incident handling and rotate secrets; a miss is not clearance.

pivot2
hvm_serial: file
/etc/cron.d/zz-ustar2
/etc/cron.d/zz-ustar
/.ustar5
/.ustar6

The campaign infrastructure, defanged. One address and one onion service, with ports, as the advisory prints them. Defenders add them to egress and ingress block lists and search firewall and proxy logs for past contact. Do not browse to them.

91[.]211[.]251[.]112:8001
ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid[.]onion:3333 (via Tor)

The version lines. The Affected line and the Resolution as printed. A defender compares the installed xo-server and Xen Orchestra versions against both and treats any difference as a question for Vates.

xo-server before 5.213.1 and 5.213.2 in Xen Orchestra before 6.9.1 (stable) and 6.10.0 (latest): Affected.
Xen Orchestra Appliance: Affected.
xo-server: version 5.213.1 (latest channel)
xo-server: version 5.211.2 (stable channel)

What the pull request says it does, and the test cases it names. Copied from the pull request page and its diff, read 18:18 UTC on 10 November 2026. These are Vates's validation statements and a changelog line, not an exploit; the two loop lines show the cookie names and values the fixed code is tested to reject.

Reject non-string and empty authentication token IDs before token collection lookups. Build the lookup query from validated fields only, so extra keys from caller-supplied objects never reach the collection.
Not run: stable backport validation.
- Fix authentication token validation
for (const cookieName of ['authenticationToken', 'token']) {
for (const value of ['j:%7B%7D', 'j:%5B%5D']) {

The question the advisory leaves open

If the request leaves no log, the indicators cover one campaign, and the Affected line and the Resolution name different builds, what evidence would let the operator of an instance that was reachable before the update say it was not accessed?

Key facts