- Vates says an authentication bypass in Xen Orchestra, tracked as VSA-2026-062, is being actively exploited and can give attackers admin rights.
- Vates says a compromised console can mean code execution on managed pools and root control of XCP-ng nodes.
- Update to 6.9.2 (stable) or 6.10.1 (latest), keep the console off the internet, and check for the indicators Vates lists.
The console that holds every key
A virtualization management console is a quiet piece of software. It can start, stop, copy and reconfigure every virtual machine a company runs.
That is why a flaw in Xen Orchestra deserves attention beyond the people who run it. Vates, the maker of Xen Orchestra, says a threat actor is already exploiting a bug that lets attackers act as an administrator without a password.
The argument here is that a console like this needs protection as strong as anything it manages. Vates says a successful exploit leaves no log entry showing unauthenticated access. A door that leaves no trace is hard to watch.
What Vates reports
Vates tracks the issue as VSA-2026-062. It rates the impact Critical and says the threat actor first operated from 91.211.251.112:8001 and a Tor onion address on port 3333.
The advisory credits Filip Magic and Christoffer Olsen, who work at TDC NET Security and are not Vates staff, with finding the flaw.
No CVE identifier or CVSS score has been assigned yet, according to BleepingComputer's coverage. Teams that search their scanners by CVE number will not find this one for now.
Vates says an attacker can bypass authentication and act with Admin privilege. In the advisory's words, a compromise "can lead to arbitrary code execution on managed pools", and the attacker can take over XCP-ng nodes with root rights.
How an empty cookie becomes an admin login
The trigger is a single cookie, but the flaw has two parts. Vates describes a chain of four steps.
First, the REST interface reads a login cookie. An attacker sends the value authenticationToken=j:%7B%7D. The cookie parser turns that into an empty object, written {}.
Second, the authentication code passes that object to the token provider. It does not require the value to be a text string, as a real token would be.
Third, the token store treats the empty object as a search with no filter. A search with no filter matches everything, so the store returns its first token.
Fourth, the provider logs the caller in as that token's owner, provided the token has not expired. The attacker can then call the /rest/v0/users/me/authentication_tokens route, which returns reusable login token IDs.
Think of a hotel desk clerk asked for a key with no room number. The clerk hands over the first key in the drawer. The analogy is loose. Here two weaknesses combine: a missing check that the value is a string, and a token lookup that treats an empty filter as match-all.
Why detection is hard
Vates says a successful exploit leaves no log entry that shows unauthenticated access. Teams that rely on application logs alone will see nothing.
Instead, Vates says the attack can be spotted by watching HTTP traffic with tools such as tcpdump or Wireshark. It also points to traces on hosts. One is any virtual machine set to use the hvm_serial: file parameter. Another is the presence of any of four files that should not exist: two cron entries named zz-ustar and zz-ustar2 under /etc/cron.d, plus .ustar5 and .ustar6 in the root directory.
Vates also warns that these indicators cover only this known campaign. In its words, other attackers using different methods cannot be ruled out. It says the absence of these indicators alone is not enough to conclude that no compromise happened.
What Vates says to do
Vates says Xen Orchestra before 6.9.2 on the stable channel, and before 6.10.1 on the latest channel, is affected. As of November 10, it says those two versions include the fix. The related xo-server packages are 5.211.2 for stable and 5.213.1 for latest.
BleepingComputer's report gives different release numbers, 6.9.1 and 6.10.0. Check the Vates advisory before you decide which build is safe.
For teams that cannot update at once, Vates lists other steps. Keep Xen Orchestra off the internet. Put it on a dedicated management network. Block the named IP address and the onion domain, and block Tor traffic. Vates also suggests blocking the empty token in a web application firewall or reverse proxy, with a caution that rules based on pattern matching can be bypassed through other formats.
If a compromise is confirmed, Vates recommends a full reinstall. It says cleanup alone cannot guarantee that every backdoor is gone. It also says configuration theft and credential harvesting cannot be ruled out, so passwords and secrets should be rotated. That includes backup remotes such as NFS, S3, Azure and SMB, the root account, the pool secret, OTP secrets and mail server passwords.
Questions to put to your infrastructure team
Ask whether any Xen Orchestra instance can be reached from the internet. Ask which version each one runs, and who owns the update.
Ask whether the team can inspect HTTP traffic to the console, since logs will not show this attack. Ask whether anyone has searched hosts for the files and VM settings Vates lists.
Ask how many secrets sit inside the console, and how quickly they could all be rotated. The answer shows how much one stolen login would cost.
The console that manages everything has to be defended as carefully as the systems it manages. The trigger here is simple, but Vates says the campaign is real and active.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Vates.
