Threat watch / Vulnerability
Xen Orchestra: an empty login token gives attackers admin over virtualization servers
On November 10, 2026, Vates, the French company behind Xen Orchestra, published a critical advisory for an authentication bypass in its virtualization management tool and the Xen Orchestra Appliance. A cookie holding an empty token logs an attacker in with admin rights, which Vates says can lead to code execution on managed pools and a full XCP-ng node takeover as root. Vates says the flaw is actively exploited and has shipped fixes.
- Sector
- Many sectors
- Way in
- Software flaw
- Product or vendor
- Xen Orchestra, Xen Orchestra Appliance, XCP-ng
- How it happened
- An authentication bypass in Xen Orchestra's REST interface (VSA-2026-062, no CVE yet): a cookie set to authenticationToken=j:%7B%7D turns into an empty object, which the token lookup treats as an unfiltered search, so the attacker is logged in as an existing token owner without credentials. It needs network access to the management interface. Vates says "an adversary can bypass authentication and perform actions with 'Admin' privilege".[1][2] Checked 10 Nov 2026
- What was stolen
- Not public yet Checked 10 Nov 2026
- Who was impacted
- Organizations running Xen Orchestra or the Xen Orchestra Appliance before the fixed versions, with the management interface reachable by the attacker. Vates confirms active exploitation but has not said how many systems were hit.[1][2] Checked 10 Nov 2026
- Threat actor
- Not attributed
Timeline
- Vates publishes VSA-2026-062, rated critical, credited to Filip Magic and Christoffer Olsen of TDC NET Security. It says the flaw "is actively exploited by a threat actor" operating from 91.211.251.112:8001 and a Tor address, and ships fixes in Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest), with xo-server 5.211.2 and 5.213.1. [1]
- Vates tells customers not to expose Xen Orchestra to the internet, to block the attacker's addresses and the empty-token pattern, and to look for a VM named pivot2 and files such as /etc/cron.d/zz-ustar. BleepingComputer notes Vates says exploitation leaves no identifiers in logs, and advises rotating virtualization passwords and secrets if compromised. [1][2]