Actively exploited Security news
Attackers exploit a critical Xen Orchestra flaw to take over XCP-ng virtualization
On 10 November 2026 Vates published security advisory VSA-2026-062 for a critical flaw in Xen Orchestra, the web management console for XCP-ng. An unauthenticated attacker can make REST API requests as the owner of a valid login token, typically an administrator, and from there run code on managed XCP-ng hosts as root. Vates says a threat actor is already exploiting it. Fixed xo-server 5.213.1 and 5.211.2 shipped the same day.
Key points
- The bug sits in how the Xen Orchestra REST API parses the authenticationToken cookie. A crafted value becomes an empty object, the token check fails to reject it, and the lookup returns the first valid token in the database – so the attacker acts as that token's owner.
- According to Vates, a compromised Xen Orchestra lets an attacker run arbitrary code on managed pools and take over XCP-ng hosts as root.
- Vates confirms active exploitation. Look for a VM named pivot2 and for /etc/ld.so.preload, /.ustar5, /.ustar6 and zz-ustar cron jobs on hosts.
- Fix: xo-server 5.213.1 (latest) and 5.211.2 (stable). No CVE or CVSS score has been assigned yet.
What happened
Vates, the French company behind the XCP-ng virtualization platform and its web console Xen Orchestra, published security advisory VSA-2026-062 on 10 November 2026, rated critical. The flaw lets an attacker bypass authentication and act with administrator rights. Vates says it is actively exploited by a threat actor operating from 91.211.251[.]112 (port 8001) and over Tor. It was discovered by Filip Magic and Christoffer Olsen of TDC NET Security. The fix (PR #10748) was merged the same day.
Technical details
The flaw is in how xo-server authenticates REST API requests:
- Component:
xo-server, REST API authentication (authenticationTokencookie). - Bug class: missing input type validation leading to authentication bypass. An empty object behaves like a query with no conditions against the token collection.
- Preconditions: network access to the Xen Orchestra web interface and at least one unexpired login token (normally created when an admin signs in). No password required.
- Impact: per Vates, admin rights in Xen Orchestra, leading to arbitrary code execution on managed pools and full takeover of an XCP-ng host as
root. Configuration exfiltration and credential harvesting (backup, S3, proxy, root) can't be ruled out.
PR #10748 rejects token IDs that aren't non-empty strings and builds the database query only from validated fields. The PR says the bug was introduced by an earlier commit; Vates doesn't say when.
Who is affected
- Xen Orchestra Appliance (XOA) and Xen Orchestra built from sources with
xo-serverolder than 5.213.1 (latest channel) or 5.211.2 (stable channel). - Internet-facing deployments are most at risk, but the attack works from any network that can reach the interface.
The advisory also lists Xen Orchestra 6.10.0 and 6.9.1 as fixed. According to the changelog, however, those releases (29 Oct and 5 Oct 2026) shipped xo-server 5.213.0 and 5.211.1 – so rely on the xo-server version number.
How to tell if you've been compromised
Indicators from the Vates advisory (IP defanged):
91.211.251[.]112 attacker infrastructure (port 8001), plus a Tor onion address (port 3333)
pivot2 name of a VM created by the attacker
/etc/ld.so.preload suspicious file on the XCP-ng host
/.ustar5 /.ustar6 attacker files in the host's root directory
/etc/cron.d/zz-ustar /etc/cron.d/zz-ustar2 attacker cron jobsChecks Vates recommends on XCP-ng hosts:
xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'
zgrep -- '-serial file:' /var/log/xensource.log*
ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*In traffic to Xen Orchestra (tcpdump, Wireshark, reverse proxy logs), look for an authenticationToken cookie with the value j:{} or j:%7B%7D. Successful exploitation leaves no entry in the Xen Orchestra log for unauthenticated access. Vates stresses that the absence of these indicators doesn't prove you weren't compromised – other actors may work differently. Our IOC extractor pulls indicators out of logs and runs entirely in your browser.
What to do
- Update Xen Orchestra to
xo-server5.213.1 (latest) or 5.211.2 (stable) – via the updater on the matching channel in XOA, or from the currentmasterbranch if you build from sources. - Take the interface off the internet. Xen Orchestra belongs on a dedicated management network, ideally reachable only over VPN.
- Block inbound and outbound traffic to
91.211.251[.]112and traffic to Tor. - Until you can patch, block requests with an
authenticationToken=j:{}/j:%7B%7Dcookie at your WAF or reverse proxy. Vates warns that regex rules can be bypassed with other encodings – treat this as a stopgap only. - After patching, revoke existing login tokens and check your hosts against the indicators.
- If in doubt, rotate every Vates VMS password and secret – proxies, backups, S3, host root and user accounts – and report the incident to your national CERT.
Timeline
FAQ
Am I exposed if Xen Orchestra isn't reachable from the internet?
The software is still vulnerable, but the attacker needs network access to it. Vates recommends running Xen Orchestra only on a dedicated management network. Patch anyway – one compromised machine on the same network is enough.
Are Xen Orchestra 6.10.0 and 6.9.1 safe?
Go by the xo-server version. The advisory lists Xen Orchestra 6.10.0 and 6.9.1 as fixed, but according to the changelog those October releases shipped xo-server 5.213.0 and 5.211.1. The fix is in xo-server 5.213.1 and 5.211.2 – check the version in Xen Orchestra (Settings → About, or the updates section in XOA).
Why is there nothing in my logs?
Vates says successful exploitation leaves no log entry for unauthenticated access, because the request looks authenticated. That's why you need to inspect network traffic and look for traces on the XCP-ng hosts.
Does this affect the Xen hypervisor or XCP-ng itself?
The flaw is only in the Xen Orchestra management application. XCP-ng hosts are still at risk because Xen Orchestra manages them with full privileges, which is why Vates lists host-side indicators too.
Sources
Spotted a mistake? Let us know and we will correct it openly.
Related
Actively exploited
BlackNevas ransomware wiped ESXi and backups after enabling SSH through vCenter Host Profiles
On 13 November 2026 Kaspersky GERT published its analysis of a BlackNevas ransomware intrusion that encrypted four ESXi hosts with every virtual machine on them, both vCenter appliances and the backup infrastructure. No VMware vulnerability was needed: credentials stolen from other systems and everyday vCenter features were enough. Here is how it unfolded, the indicators, and what to monitor.
Actively exploited
Attackers abuse GSocket for stealthy access to Linux servers
On 11 November 2026 Microsoft published an analysis of intrusions in which attackers, after breaking in through a vulnerable web application, install the legitimate open-source tool GSocket on Linux servers. The connection goes out through a shared relay network, so inbound firewall rules never see it, and the attackers keep access even after the original flaw is patched. The write-up includes paths, hashes, domains and hunting queries.
Actively exploited
Cisco BroadWorks: an August XXE flaw is now exploited, and attackers are stealing server private keys
Run Cisco BroadWorks? CVE-2026-20320 has been fixed since 19 August 2026, but CISA added it to its exploited list on 10 November. Malbear Labs has described an intrusion at a European telecoms provider in which the attacker used it to steal the server's private keys and certificates.