Vates published security advisory VSA-2026-062 on 10 November 2026, and it is not a routine patch notice. A critical authentication bypass in Xen Orchestra, the web console that manages XCP-ng virtualization pools, is being actively exploited in the wild. An attacker with network access to the management interface needs no credentials at all: a single crafted cookie is enough to walk in as an administrator. From there, Vates says, compromise can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root.
If you run XCP-ng with Xen Orchestra, treat this as a patch-today flaw. The rest of this article is the operator playbook: what broke, how to tell if you were hit, and what to do in which order.
An empty object that passes as a login
The bug is almost embarrassingly small. Xen Orchestra's REST authentication reads the authenticationToken cookie, and the cookie parser turns the value j:%7B%7D into an empty JSON object, {}. That object is handed to the token provider without any check that it is actually a string. The token store then treats {} as an unfiltered lookup and returns its first token. If that token has not expired, the attacker is authenticated as its owner, no password asked.
It gets worse from there. The authenticated route /rest/v0/users/me/authentication_tokens then hands back reusable login token IDs, so one lucky guess at the first token becomes a durable set of credentials. The flaw was discovered by Filip Magic and Christoffer Olsen of TDC NET Security, and the fix landed the same day in upstream pull request #10748, which rejects non-string and empty token IDs.
No CVE identifier or CVSS score had been assigned when the advisory went out, so do not wait for a CVE number to appear in your scanner before acting. The vendor's own severity rating is Critical, and the vendor confirms live exploitation. That is the whole triage.
Why this one is worse than a normal patch
Three facts make VSA-2026-062 nastier than the average auth bug.
First, it is already being used. Vates names the attacker's infrastructure outright: traffic from 91.211.251.112:8001 and a Tor onion service, ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333. This is a campaign with a command-and-control channel, not a proof of concept sitting in a researcher's drawer.
Second, a successful break-in leaves no trace in the application logs. Vates is explicit: the crafted cookie does not show up in Xen Orchestra's logs, so grepping for the exploit string after the fact proves nothing. Detection has to happen at the network layer, by watching HTTP requests for authenticationToken=j:%7B%7D or authenticationToken=j:{} with tcpdump or Wireshark, or on the hosts themselves.
Third, the attacker plants persistence. The published indicators include a rogue pivot2 VM, hosts carrying an hvm_serial: file platform parameter, cron files named /etc/cron.d/zz-ustar and /etc/cron.d/zz-ustar2, and files called /.ustar5 and /.ustar6 plus a modified /etc/ld.so.preload. Those are the footprints of an intruder who plans to stay, which is why the advisory says a confirmed compromise calls for a full reinstallation rather than cleanup alone.
The patch playbook
Work through these in order. Do not skip the backup step just because the patch looks small.
1. Patch Xen Orchestra now. The fix is in Xen Orchestra 6.9.2 on the stable channel and 6.10.1 on the latest channel, which carry xo-server 5.211.2 and 5.213.1 respectively. If you installed from source, update to the latest master. This is the same week the Xen ecosystem already had a rough one: seven stable kernels shipped on 6 November with guest-to-host Xen fixes, so if your maintenance window is still warm, use it.
2. Take a snapshot before you touch anything. Patching a management console is low risk, but hunting for compromise afterwards is not. A known-good restore point is what lets you roll back instead of guessing. If your backup routine is rusty, our Timeshift guide walks through full-system snapshots on Linux.
3. Check whether the console was ever reachable from the internet. Xen Orchestra belongs on a dedicated management network, never on a public address. If yours was exposed, assume it was probed: the flaw needs only network access to the interface, and the campaign was already scanning. Close the exposure first, then patch, then hunt. The same discipline applies to every service you expose, which is why our SSH hardening audit starts from the same question: who can even reach this port?
4. Hunt for the campaign's footprints. On Xen Orchestra, watch live HTTP traffic for the empty-token cookie patterns. On every XCP-ng host, look for a VM named pivot2, check xe vm-list params=name-label,platform for hvm_serial: file, search the host logs with zgrep -- '-serial file:' /var/log/xensource.log*, and list /etc/ld.so.preload, /.ustar*, and /etc/cron.d/zz-ustar*. Treat any hit as a confirmed incident, not a curiosity.
5. Block the attacker's infrastructure at the edge. Add ingress and egress filters for the published IPs, starting with 91.211.251.112, and block Tor traffic to the onion address. Vates also suggests a WAF or reverse-proxy rule matching the empty-token cookie, with a warning that regexes can be bypassed with other encodings, so treat that as a tripwire, not a fix.
6. Rotate everything if there is any sign of compromise. Configuration exfiltration and credential harvesting cannot be ruled out once an attacker had admin access, so rotate pool secrets, root and user passwords, OTP secrets, backup remote credentials for NFS, S3, Azure, and SMB, and mail server passwords. And remember the advisory's bluntest line: if compromise is confirmed, reinstall. Cleanup alone cannot guarantee the backdoors are gone.
The pattern to remember
This is the second week in a row the Xen world has had to patch in a hurry, and the two flaws rhyme. The kernel bugs last week and this management-plane bug both came down to a lookup that trusted its input too much. The lesson for anyone running virtualization infrastructure is boring and therefore easy to skip: the management console is part of the attack surface, it deserves the same patch urgency as the hypervisor, and it should never be reachable from the internet in the first place.
The CVE-2026-98432 kernel flaw taught the same lesson days ago from the other side: patch fast, verify the running version instead of trusting the upgrade job, and keep a snapshot so you can prove what changed. Do the same here, and do it today.
