Critical Xen Orchestra Flaws Exploited in Attacks

What happened

A threat actor is exploiting a critical authentication bypass and a zero-day in Xen Orchestra, according to its maker Vates. The bypass lets unauthenticated attackers gain administrator privileges. SecurityWeek reported the warning.

Xen Orchestra is a web-based backup, management and disaster recovery tool for XCP-ng and XenServer. It acts as an agentless control center across hosts, VMs, storage and pools. Whoever controls it controls a lot.

The flaw sits in the REST authentication mechanism. An authentication token is turned into {} and then treated as an unfiltered lookup. The token collection returns the first token, and if that token is not expired, the provider authenticates as its owner.

The result is a route that exposes reusable login token IDs. Vates says a compromise "can lead to arbitrary code execution on managed pools and a full XCP-ng node takeover as root."

Who is affected and what is fixed

The defect hits Xen Orchestra releases before 6.9.2 (stable) and 6.10.1 (latest). It also hits the Xen Orchestra Appliance, which contains Xen Orchestra.

If you run XCP-ng or XenServer pools and manage them through Xen Orchestra, assume you are in scope until you confirm your version.

How serious it is and whether it is exploited

This is serious, and it is exploited. Vates says the same threat actor has used the bypass and a separate zero-day. The zero-day requires administrator privileges and allows malicious VM imports that could compromise XCP-ng hosts.

The two flaws chain well. The bypass hands an attacker admin rights without a password. The zero-day then helps reach the hosts underneath.

Vates reports that the attacker first operated from 91.211.251.112:8001 and also used the Tor network. No CVE identifier has been assigned to either defect.

The hardest part is detection. Vates warns that unauthorized access is not logged. Its indicators of compromise (IoCs) cover this specific campaign only. In Vates' words, "The absence of these IoCs alone is not sufficient to conclude that no compromise has occurred."

The fix for the zero-day is not released yet. Check the Vates announcement for updates.

What to do now

Work through this list in order.

1. Update Xen Orchestra to 6.9.2 (stable) or 6.10.1 (latest). Update the Appliance too.

2. Isolate the instance. Vates recommends placing Xen Orchestra behind a dedicated network.

3. Block the known malicious IP addresses and domain names from the IoC list.

4. Add a WAF rule that blocks the empty token.

5. Rotate all potentially compromised credentials.

6. Hunt for signs of the known campaign, as shown below.

Check exposure and known indicators

First, see what is listening on the host and who is connected. These are generic Linux commands, so adjust paths for your setup.

sudo ss -tlnp
sudo ss -tnp | grep "91.211.251.112"

Next, search your logs for the attacker address Vates published.

sudo grep -rI "91.211.251.112" /var/log/ 2>/dev/null

This only covers reverse proxy, firewall and system logs if they are stored under /var/log on that host. Also search the logs held on your separate proxy or firewall appliances.

An empty result does not clear you, because unauthorized access is not logged by Xen Orchestra. Treat it as one signal only.

Then block the address at the host firewall while you work through the full IoC list from Vates.

sudo iptables -I INPUT -s 91.211.251.112 -j DROP
sudo iptables -I OUTPUT -d 91.211.251.112 -j DROP

Worked example: a three-host pool

Say you run a small XCP-ng pool with three hosts. Xen Orchestra sits on a VM in the same network as your guests, with its web port open to the office LAN and VPN.

• Check the version first. If it is below 6.9.2 or 6.10.1, update now.

• Move the Xen Orchestra VM to a management network that only admins can reach.

• Search the proxy and firewall logs for 91.211.251.112 and for Tor exit traffic.

• Rotate the admin passwords, API tokens and any stored host credentials.

• Review recently imported VMs, since the zero-day abuses VM imports.

Decide what to do after the check

Vates is blunt about the last row: "cleanup alone cannot guarantee the removal of all backdoors left by the attacker." A root takeover of an XCP-ng node means you should rebuild, not patch in place.

We covered the same incident in our earlier post, Critical Xen Orchestra Auth Bypass Exploited to Hijack VMs.

What learners can take from this

This case shows why management planes are prime targets. One console with admin rights over every host is worth more to an attacker than any single server. Network segmentation, WAF rules and credential rotation are the controls Vates recommends here.

It also shows a common detection problem: when a product does not log the abuse, you need other evidence. Firewall, proxy and network logs fill that gap. If you want to practice this kind of triage, the CompTIA CySA+ CS0-003 voucher covers threat detection and response. The code is emailed within 12 hours of payment and also shown in your account.

Sources

• SecurityWeek: Critical Xen Orchestra Flaws Exploited in Attacks