{"id":4164,"date":"2026-11-11T07:08:49","date_gmt":"2026-11-11T15:08:49","guid":{"rendered":"https:\/\/cyber.mag212.com\/xen-orchestra-vsa-2026-062-empty-object-token-exploited-xcp-ng-root\/"},"modified":"2026-11-11T07:08:49","modified_gmt":"2026-11-11T15:08:49","slug":"xen-orchestra-vsa-2026-062-empty-object-token-exploited-xcp-ng-root","status":"publish","type":"post","link":"https:\/\/cyber.mag212.com\/fr\/xen-orchestra-vsa-2026-062-empty-object-token-exploited-xcp-ng-root\/","title":{"rendered":"Xen Orchestra Auth Bypass (VSA-2026-062) Is Exploited: An Empty-Object Cookie Hands Over XCP-ng Hosts"},"content":{"rendered":"\n

Xen Orchestra, the web console many MSPs, hosting providers and schools use to run XCP-ng virtualisation, has a critical authentication bypass that is already being exploited. Vates\u2019 advisory VSA-2026-062 explains that a crafted login cookie is parsed into an empty object that the token check accepts. From there an attacker is an Xen Orchestra administrator, can run code across pools and ends up as root on the hosts. There is no CVE yet, and Vates warns that successful exploitation leaves no log entry.<\/p>\n\n\n\n

Advisory<\/strong><\/td>Vates VSA-2026-062 \u00b7 Critical<\/td><\/tr>
Fixed<\/strong><\/td>XO 6.9.2 (stable) \u00b7 6.10.1 (latest)<\/td><\/tr>
CVSS<\/strong><\/td>Not available yet<\/td><\/tr>
Logs<\/strong><\/td>Exploitation leaves none<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What happened<\/h2>\n\n\n\n

[Confirmed]<\/strong> Vates rates VSA-2026-062, “Empty-object login token”, Critical and says it is being actively exploited by an actor operating initially from 91.211.251.112:8001<\/code> and an onion address. There is no CVE yet. (Vates<\/a>) [Reported]<\/strong> Credited to Filip Magic and Christoffer Olsen (TDC NET Security); THN adds that VirusTotal flags that IP as a RedLine Stealer C2. A crafted cookie, authenticationToken=j:%7B%7D<\/code>, is parsed into an empty object that the token provider accepts, giving XO admin, then code execution on pools and root on hosts. (The Hacker News<\/a>) [Unknown]<\/strong> Start date and victim count.<\/p>\n\n\n\n

\"Five-step
Figure 3 \u00b7 From an empty cookie to root on XCP-ng.<\/strong> The reported bypass mechanics, with the vendor’s fixed versions and response order. Exploitation leaves no logs. Diagram: MAG212 CYBER<\/figcaption><\/figure>\n\n\n\n

Who is affected<\/h2>\n\n\n\n
Install type<\/th>Affected<\/th>Fixed (vendor)<\/th><\/tr><\/thead>
Xen Orchestra, stable channel<\/td>before 6.9.2<\/td>XO 6.9.2<\/strong> (xo-server 5.211.2)<\/td><\/tr>
Xen Orchestra, latest channel<\/td>before 6.10.1<\/td>XO 6.10.1<\/strong> (xo-server 5.213.1)<\/td><\/tr>
Xen Orchestra Appliance (XOA)<\/td>yes<\/td>update to the versions above<\/td><\/tr>
From-sources builds<\/td>yes<\/td>latest master (PR #10748)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Source: Vates<\/a>. Conflict:<\/strong> THN gives 6.9.1 \/ 6.10.0 with the same xo-server versions; we use the vendor’s figures.<\/em><\/p>\n\n\n\n

What to look for (vendor IOCs)<\/h2>\n\n\n\n
Type<\/th>Indicator (all from Vates VSA-2026-062)<\/th><\/tr><\/thead>
Request pattern<\/td>authenticationToken=j:%7B%7D<\/code> or j:{}<\/code><\/td><\/tr>
Host artifacts<\/td>a VM named pivot2<\/code>; VMs with hvm_serial: file<\/code><\/td><\/tr>
Files<\/td>\/etc\/cron.d\/zz-ustar2<\/code>, \/etc\/cron.d\/zz-ustar<\/code>, \/.ustar5<\/code>, \/.ustar6<\/code><\/td><\/tr>
IPs to block<\/td>91.211.251.112<\/code> 193.148.56.72<\/code> 37.221.208.216<\/code> 45.66.35.11<\/code> 64.65.0.120<\/code> 64.65.62.160<\/code> 89.47.51.90<\/code> 92.60.37.247<\/code><\/td><\/tr>
Onion C2<\/td>ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vendor caveat:<\/strong> successful exploitation leaves no log entry, and finding no IOCs does not prove a host is clean. Vates<\/a><\/em><\/p>\n\n\n\n

Host checks<\/h3>\n\n\n\n

OS: XCP-ng (dom0) \u00b7 Shell: bash \u00b7 Privileges: root (MAG212 analysis; vendor doesn't state) \u00b7 READ-ONLY<\/em><\/p>\n\n\n\n

# VMs whose platform settings include a file-backed serial port (IOC: hvm_serial: file)\nxe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'\n# Search current and rotated xensource logs for file-backed serial configuration\nzgrep -- '-serial file:' \/var\/log\/xensource.log*\n# Preload hijack and the published persistence files\nls -la \/etc\/ld.so.preload \/.ustar* \/etc\/cron.d\/zz-ustar*<\/code><\/pre>\n\n\n\n
Run on every XCP-ng host. Any output naming the IOCs above is a hit; “No such file” for the last command is the expected clean result. Commands not tested by MAG212 CYBER<\/strong>; copied from the Vates advisory<\/a>.<\/p>\n\n\n\n
Contain and remediate (in order, per Vates)<\/h2>\n\n\n\n
    \n
  1. Take XO off the internet<\/strong> onto a dedicated management network; block the IPs and onion address.<\/li>\n\n\n
  2. Upgrade<\/strong> to XO 6.9.2 or 6.10.1 (xo-server 5.211.2 \/ 5.213.1); from-sources builds to latest master.<\/li>\n\n\n
  3. Optional interim WAF or reverse-proxy rule for the token patterns; Vates warns regex rules can be bypassed.<\/li>\n\n\n
  4. Run the host checks<\/strong> above on every host.<\/li>\n\n\n
  5. If compromised:<\/strong> rotate all secrets (proxy, backup remotes, root, pool secret, users, OTP, mail) and fully reinstall. (Vates<\/a>)<\/li>\n\n<\/ol>\n\n\n\n
    Verify recovery:<\/strong> confirm the XO version, that the interface is unreachable from untrusted networks, re-run the checks, and confirm rotated secrets are in use. [MAG212 analysis]<\/strong> With no logs, reinstalling is the only high-confidence recovery for a host with any hit. Virtualisation control planes belong on an isolated network, especially for MSPs and schools that chose XCP-ng to save cost.<\/p>\n\n\n\n
    Why it matters<\/h2>\n\n\n\n
    A virtualisation control plane is a master key: whoever holds it can snapshot, copy, modify or destroy every virtual machine it manages. Organisations that chose XCP-ng to save licence costs often run lean IT teams that publish the console for convenience. Because exploitation is silent, a clean log review proves nothing.<\/p>\n\n\n\n
    The bottom line<\/h2>\n\n\n\n
    Take Xen Orchestra off the internet now, upgrade to 6.9.2 or 6.10.1, run the vendor\u2019s host checks on every XCP-ng host, and if anything matches, rotate every secret and rebuild rather than clean.<\/p>\n\n\n\n
    How we label evidence: [Confirmed]<\/strong> comes from a primary source such as a vendor or CISA; [Reported]<\/strong> from a secondary outlet; [Claimed]<\/strong> from an attacker or an unverified party; [MAG212 analysis]<\/strong> is our judgement; [Unknown]<\/strong> means not established at press time. Commands and indicators are copied from the cited sources and were not tested by MAG212 CYBER.<\/em><\/p>\n\n\n\n
    \n\n\n\n
    This story is part of MAG212 CYBER Daily, 11 November 2026<\/a>, with the day\u2019s other verified stories, the Defender\u2019s Action Desk and a full source register. Get the daily briefing free: subscribe to MAG212 CYBER<\/a>. By El Mostafa Ouchen.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
    Vates warns that a critical Xen Orchestra flaw is being actively exploited: a crafted cookie parsed as an empty object passes authentication, giving admin control, code execution on pools and root on XCP-ng hosts. Fixed versions, vendor IOCs, host checks and why reinstalling may be the only safe recovery.<\/p>","protected":false},"author":1,"featured_media":4162,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[19,15,14],"tags":[308,263,307,306,305],"class_list":["post-4164","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-critical-cves","category-threat-intelligence","category-vulnerabilities","tag-authentication-bypass","tag-iocs","tag-virtualization","tag-xcp-ng","tag-xen-orchestra"],"_links":{"self":[{"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/posts\/4164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/comments?post=4164"}],"version-history":[{"count":0,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/posts\/4164\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/media\/4162"}],"wp:attachment":[{"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/media?parent=4164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/categories?post=4164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cyber.mag212.com\/fr\/wp-json\/wp\/v2\/tags?post=4164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}