Xen Orchestra Authentication Bypass Is Being Used to Take Over Virtualisation Hosts

What happened

Vates, the French company behind Xen Orchestra, has confirmed that a critical authentication bypass in its management platform is being exploited in live attacks. Xen Orchestra is a web-based console for administering XCP-ng virtualisation environments, including virtual machines, hosts and pools. The flaw is tracked as VSA-2026-062 and affects both Xen Orchestra and the Xen Orchestra Appliance. No CVE identifier or CVSS score has been assigned yet. A remote attacker with network access to the management interface can sign in without credentials by sending a specially crafted cookie that carries an empty JSON object. The platform responds by retrieving an existing authentication token and treating the attacker as that token's owner. From there, the attacker can pull reusable login token IDs through a REST API endpoint and keep their access. Vates warns that this allows actions with administrator privilege, code execution on managed pools and a full takeover of XCP-ng nodes as root.

Vates has released Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest), which include patched xo-server packages 5.211.2 and 5.213.1. Administrators who cannot update immediately are advised to restrict access to dedicated management networks and block the known malicious IP addresses. The flaw was found by researchers Filip Magic and Christoffer Olsen of TDC NET Security. Vates has published indicators of compromise tied to the current campaign: connections to specific attacker infrastructure, a virtual machine named pivot2, virtual machines configured to use a file for the serial port, and unusual files in cron directories and the root of the filesystem. The detail that matters most for defenders is that exploitation does not leave identifiers in logs. Detection depends on HTTP monitoring, and Vates cautions that other threat actors may leave different traces. Organisations that think they are compromised should rotate the passwords and secrets used by their virtualisation environments.

Why it matters for organisations in Africa, the Gulf and beyond

A virtualisation management console is one of the most valuable targets in an estate. It does not hold one application or one server. It controls the platform on which many of them run. When an attacker reaches administrator level there, the question is no longer which workload was affected but which workloads can still be trusted. Vates describes a path from a forged cookie to root on the host, which is why a flaw in the management plane deserves the same urgency as one in an internet-facing gateway. DAAKYI made a similar point when covering the Ivanti Connect Secure exploit chain, where an authentication bypass was the first step towards credentials and wider access.

For organisations in Africa, the Gulf and beyond, the lesson is practical. Many run mixed estates in which some workloads sit on in-house virtualisation, some with hosting providers and some in public cloud, often looked after by small teams or third parties. Open-source virtualisation and its management tools are a sensible choice for cost and control, but they are easy to leave outside the patching, asset and monitoring routines applied to better-known products. A console that was exposed for convenience, or reachable from a wider network than anyone intended, becomes the weak point. Where regulated or critical workloads are kept in jurisdiction for sovereignty reasons, the management layer is part of that boundary and needs to be defended as such.

The second lesson is about detection. Because the exploit leaves no log entries, an organisation that relies on log review alone could be compromised and not know it. Leaders should ask whether anyone is watching HTTP traffic to management interfaces, whether those interfaces are reachable only from controlled networks, and who owns the answer. The pattern of attackers using a trusted administrative tool to reach many systems at once is not new, and it will not remain confined to one product.

What leaders should do now

Treat this as an urgent management-plane exposure and ask your infrastructure owners to confirm the following.

• Confirm whether Xen Orchestra or the Xen Orchestra Appliance is in use anywhere, including with hosting providers and in test environments, and update to 6.9.1 or 6.10.0 without delay.
• Where updating is not immediate, restrict the console to a dedicated management network and block the malicious IP addresses published by Vates.
• Check hosts and consoles against the Vates indicators, including the pivot2 virtual machine, serial port file settings and the unusual cron and root-level files.
• Add HTTP monitoring for requests to management interfaces that carry the crafted cookie, since logs will not record this exploitation.
• If compromise is suspected, rotate the passwords and secrets used by the virtualisation environment and preserve evidence before rebuilding anything.
• Review which administrative consoles are reachable from user or internet-facing networks, and record an owner for each.

How DAAKYI can help

DAAKYI helps organisations find exposures like this before attackers do and clear them quickly. Continuous Threat Exposure Management gives a current view of which management interfaces and platforms are reachable, and Managed Vulnerability Remediation turns that view into tracked fixes with named owners.

If there is any sign that a host has already been touched, DAAKYI's threat hunting work can look for the indicators Vates has published and for behaviour that falls outside them, including activity that leaves no log entries. Where the console should never have been broadly reachable, our Zero Trust Architecture work helps limit administrative access to the people, devices and networks that need it.

• Continuous Threat Exposure Management
• threat hunting
• Zero Trust Architecture

Sources

• Critical Xen Orchestra auth bypass flaw exploited to hijack VM servers (BleepingComputer)