DEV Community

Shar z
Shar z

Posted on

Xen Orchestra VSA-2026-062: An Empty Cookie That Hands Attackers Admin on Your Virtualization Plane

#security #cybersecurity #virtualization #devops

On November 10, 2026, Vates published VSA-2026-062, a Critical authentication bypass in Xen Orchestra (XO) and the Xen Orchestra Appliance (XOA), and said it is being actively exploited. There is no CVE or CVSS score yet. If you manage XCP-ng pools with Xen Orchestra, this one deserves attention today.

What happened

According to the Vates advisory, XO's REST cookie parsing turns authenticationToken=j:%7B%7D into an empty JavaScript object {}. REST authentication passes that object to the token provider without checking that it is a string. The token collection treats {} as an unfiltered lookup and returns its first token, and if that token is unexpired, the request is authenticated as its owner. The authenticated route /rest/v0/users/me/authentication_tokens then returns reusable login token IDs.

Vates' impact statement: an adversary can act with Admin privilege, and an XO compromise can lead to arbitrary code execution on managed pools and full XCP-ng host takeover as root.

The flaw was discovered by Filip Magic (@mad31k) and Christoffer Olsen of TDC NET Security, and fixed in PR #10748.

Who is affected

  • Xen Orchestra before 6.9.2 (stable) and 6.10.1 (latest), plus XOA.
  • Fixed xo-server packages: 5.211.2 (stable) and 5.213.1 (latest).
  • Note: early news coverage cited 6.9.1 / 6.10.0; the current Vates advisory lists 6.9.2 / 6.10.1 as the fixed releases, so go by the advisory.

Vates says most XO deployments aren't Internet-facing, which lowers the odds of exploitation, but an exposed instance needs urgent action.

Observed attack activity (from the advisory)

  • Threat actor initially operating from 91.211.251[.]112:8001 and a Tor onion service on port 3333. The Hacker News notes VirusTotal flags that IP as a RedLine Stealer C2.
  • Additional IPs to block: 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.
  • A running VM named pivot2, VMs configured with hvm_serial: file, and persistence files /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5, /.ustar6. Vates' check command also looks at /etc/ld.so.preload.

Detection

Vates warns that successful exploitation leaves no log entry for the unauthenticated access, so you need network visibility:

  1. Watch HTTP traffic to XO (tcpdump, Wireshark, proxy or WAF logs) for authenticationToken=j:%7B%7D or authenticationToken=j:{}.
  2. On XCP-ng hosts, run the advisory's checks:
    • 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*
  3. Look for unexpected VMs (especially pivot2), imports, sessions, and API tokens.

Vates is clear that these IoCs cover only this campaign; not finding them doesn't prove you're clean.

Mitigation

  1. Patch now: XOA to 6.10.1 (latest) or 6.9.2 (stable); from-source installs should pull the latest master and rebuild xo-server.
  2. Get XO off the Internet: VPN, dedicated management network, or IP allow-list.
  3. Block the IoC infrastructure in both directions, and block Tor egress from the management network.
  4. Temporary WAF/reverse-proxy rule matching the empty-object token patterns. Vates cautions that regex rules can be bypassed with other encodings, so this is a stopgap, not a fix.
  5. If compromised: revoke all sessions and API tokens, rotate every secret XO touches (host root passwords, pool secret, XO proxy, backup remotes such as NFS/S3/SMB/Azure, user passwords, OTP secrets, mail config), and plan a full reinstall, since Vates says cleanup alone can't guarantee backdoor removal.

My take

This is a classic type-confusion bug: a value that should be a string arrives as an object and quietly becomes a "match anything" query. Two lessons beyond the patch. First, management planes (hypervisor consoles, backup servers, NAS admin UIs) should never face the Internet, however current they are. Second, persistence like cron drops and /etc/ld.so.preload is exactly what file integrity monitoring catches when logs are silent. For NAS environments, our open-source NAS Sentinel takes that FIM-plus-persistence-check approach; whatever tool you use, baseline your critical paths so a change like this raises an alert.

Sources

Shar Z, Security Engineer at Nine-Security

中文版

Vates 於 2026 年 11 月 10 日發布 VSA-2026-062，這是 Xen Orchestra（XO）與 Xen Orchestra Appliance（XOA）的重大（Critical）身分驗證繞過漏洞，且已遭實際攻擊利用。目前尚未配發 CVE 與 CVSS 分數。如果你用 Xen Orchestra 管理 XCP-ng 資源池，今天就該處理。

發生了什麼

根據 Vates 公告，XO 的 REST cookie 解析會把 authenticationToken=j:%7B%7D 轉成空物件 {}；REST 驗證流程未檢查它是否為字串，就直接交給 token provider。token 集合把 {} 當成「不篩選」的查詢，回傳第一筆 token，只要該 token 未過期，請求就會以該 token 擁有者身分通過驗證。接著已驗證的 /rest/v0/users/me/authentication_tokens 路由還會回傳可重複使用的登入 token ID。

Vates 對影響的描述：攻擊者可取得 Admin 權限，進而在受管資源池上執行任意程式碼，並以 root 完全接管 XCP-ng 主機。

漏洞由 TDC NET Security 的 Filip Magic（@mad31k）與 Christoffer Olsen 發現，修補位於 PR #10748。

影響範圍

  • Xen Orchestra 6.9.2（stable）與 6.10.1（latest）之前的版本，以及 XOA。
  • 已修補的 xo-server：5.211.2（stable）、5.213.1（latest）。
  • 注意：早期新聞報導寫的是 6.9.1 / 6.10.0，但 Vates 最新公告列出的修補版本是 6.9.2 / 6.10.1，請以公告為準。

Vates 表示多數 XO 部署並未對外開放，降低了被利用的機率；但若你的 XO 可從網際網路存取，請立即處理。

已觀察到的攻擊跡象（出自公告）

  • 攻擊者最初來自 91.211.251[.]112:8001 以及一個 Tor onion 服務（port 3333）。The Hacker News 指出 VirusTotal 將該 IP 標記為 RedLine Stealer C2。
  • 其他建議封鎖的 IP：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。
  • 名為 pivot2 的執行中 VM、設定 hvm_serial: file 的 VM，以及持久化檔案 /etc/cron.d/zz-ustar、/etc/cron.d/zz-ustar2、/.ustar5、/.ustar6；Vates 提供的檢查指令也會檢查 /etc/ld.so.preload。

偵測方式

Vates 特別提醒：成功利用時，未經驗證的存取不會留下任何日誌，因此必須靠網路層監看：

  1. 監看送往 XO 的 HTTP 流量（tcpdump、Wireshark、反向代理或 WAF 日誌），搜尋 authenticationToken=j:%7B%7D 或 authenticationToken=j:{}。
  2. 在 XCP-ng 主機上執行公告中的檢查：
    • 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*
  3. 檢查是否有異常 VM（特別是 pivot2）、匯入、工作階段與 API token。

Vates 也強調這些 IoC 只涵蓋這波攻擊，找不到不代表沒事。

緩解措施

  1. 立即更新：XOA 升級到 6.10.1（latest）或 6.9.2（stable）；從原始碼安裝者請更新到最新 master 並重建 xo-server。
  2. 不要讓 XO 暴露在網際網路：改走 VPN、專用管理網段或 IP 白名單。
  3. 雙向封鎖 IoC 基礎設施，並阻擋管理網段的 Tor 對外連線。
  4. WAF／反向代理暫時規則：比對空物件 token 字串。Vates 提醒正規表示式可被其他編碼繞過，只能當過渡手段。
  5. 若已遭入侵：撤銷所有工作階段與 API token，輪替 XO 用到的所有機密（主機 root 密碼、pool secret、XO proxy、NFS/S3/SMB/Azure 備份目的地、使用者密碼、OTP secret、郵件設定），並規劃完整重裝，因為 Vates 表示單靠清理無法保證移除所有後門。

我的看法

這是典型的型別混淆：本該是字串的值變成物件，悄悄變成「全部符合」的查詢。修補之外有兩點值得記住：第一，虛擬化主控台、備份伺服器、NAS 管理介面這類管理平面，不管多新都不該直接面向網際網路；第二，當日誌一片安靜時，cron 落地檔與 /etc/ld.so.preload 這類持久化手法，正是檔案完整性監控（FIM）能抓到的。在 NAS 環境，我們的開源專案 NAS Sentinel 就是採用 FIM 加持久化檢查的思路；無論用什麼工具，都建議為關鍵路徑建立基準線，讓這類變動能即時告警。

參考來源

Shar Z，Nine-Security 資安工程師

Top comments (0)