Skip to content
Hacker Posts

Xen Orchestra auth bypass exploited to root XCP-ng hosts (VSA-2026-062)

A crafted cookie bypasses authentication in Xen Orchestra, granting admin and code execution on managed pools. Vates confirms active exploitation. Patch now.

Published 2 min read
cvexen-orchestravatesadvisoryexploited

Vates confirms a threat actor is actively exploiting a critical authentication bypass in Xen Orchestra (XO), the web management layer for XCP-ng. An unauthenticated attacker sends a crafted cookie, lands Admin privileges, and from there can execute code on managed pools and take over an XCP-ng node as root. The advisory is VSA-2026-062. No CVE or CVSS has been assigned yet. If your XO is reachable, treat this as an active incident.

What the bug does

Per Vates and reporting by The Hacker News, XO's REST cookie parser turns a crafted authenticationToken value into an empty object, which the token lookup then treats as unfiltered. The authenticated token-listing route returns reusable login-token IDs, handing the attacker a valid session. The chain ends at root on the hypervisor node the XO instance manages.

The flaw was reported by Filip Magic (@mad31k) and Christoffer Olsen of TDC NET Security. Vates says it is unclear when exploitation began or whether it was used as a zero-day.

Affected and fixed versions

  • Affected: Xen Orchestra before 6.9.2 (stable) and 6.10.1 (latest), and the Xen Orchestra Appliance.
  • Fixed: xo-server 5.211.2 (stable channel) and 5.213.1 (latest channel), per Vates and BleepingComputer.

Detection — indicators of compromise

Vates published IOCs for this campaign. Reproduced verbatim from VSA-2026-062:

Xen Orchestra HTTP request patterns:
  authenticationToken=j:%7B%7D
  authenticationToken=j:{}

Initial infrastructure:
  91.211.251.112:8001
  ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333 (via Tor)

Additional IPs listed for blocking:
  193.148.56.72
  37.221.208.216
  45.66.35.11
  64.65.0.120
  64.65.62.160
  89.47.51.90
  92.60.37.247

VM name:
  pivot2

Host-side checks and file paths:
  xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'
  zgrep -- '-serial file:' /var/log/xensource.log*
  /etc/cron.d/zz-ustar2
  /etc/cron.d/zz-ustar
  /.ustar5
  /.ustar6
  ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

Vates notes these cover this campaign only; their absence does not rule out compromise.

Action checklist

  1. Upgrade now to the patched xo-server builds (5.211.2 stable / 5.213.1 latest), or XO 6.9.2 / 6.10.1 and the fixed Appliance.
  2. Get XO off the internet. Vates' top mitigation is to not expose XO instances publicly. Put them behind a VPN or management network.
  3. Block the IOCs at the perimeter: the empty-token cookie pattern in a WAF/reverse proxy, plus the listed IPs and onion address.
  4. Hunt for compromise using the host-side checks above — the zz-ustar cron files, the pivot2 VM, and hvm_serial: file parameters.
  5. Rotate all passwords and secrets reachable from the XO host if any indicator is found; the C2 at 91.211.251[.]112 is flagged on VirusTotal as a RedLine Stealer server.

Context

Virtualization management planes are the quiet high-value target: one XO or vCenter box holds the keys to every VM in the estate. This lands the same week Microsoft shipped 1,000-plus CVEs — but an internet-exposed, actively-exploited auth bypass with published IOCs outranks a patch-cycle backlog. Fix the exposed thing first.

Related stories