Xen Orchestra VSA-2026-062 Exploit: Patch and Mitigate

If you run Xen or XCP-ng, treat this as a hypervisor-takeover emergency. Between November 10 and 12, 2026, French virtualization software maker Vates VMS warned that threat actors are actively using the Xen Orchestra VSA-2026-062 exploit in the wild to gain unauthenticated administrative control over Xen Orchestra web management consoles, according to SecurityWeek and The Hacker News.

Xen Orchestra is the central web interface used to administer Xen and XCP-ng hypervisor clusters. Data center infrastructure teams, cloud hosting providers, and security operations centers (SOCs) that manage open-source virtualization stacks are the ones most exposed.

The damage does not stop at the console. As reported by BleepingComputer and MLQ News, Vates confirmed that the same threat actor is chaining the authentication bypass (VSA-2026-062) with a second, still-unpatched zero-day vulnerability in virtual machine (VM) imports to achieve root code execution on the underlying XCP-ng virtualization hosts.

There is a further complication. Unauthorized logins through the cookie bypass are not recorded in standard logs. That makes immediate patching, network isolation, and forensic triage a necessity, not a nice-to-have.

Quick Answer

The Xen Orchestra VSA-2026-062 exploit abuses a critical cookie-parsing flaw (authenticationToken=j:{}) that lets unauthenticated attackers log into Xen Orchestra and Xen Orchestra Appliance instances as an administrator, with no password and no login logs. Attackers are actively chaining VSA-2026-062 with an unpatched VM-import zero-day to hijack XCP-ng hypervisor hosts as root. Update to 6.10.0 or 6.9.1 and isolate consoles immediately.

What Happened and Incident Timeline

Xen Orchestra (XO) and the turnkey Xen Orchestra Appliance (XOA) act as the central orchestration plane for enterprise and cloud-provider environments running XCP-ng and XenServer hypervisor pools. Because Xen Orchestra holds privileged API credentials to manage virtual machines on every connected hypervisor host, compromising one exposed console exposes the entire cluster.

Confirmed Facts

• Active Exploitation of VSA-2026-062 via Empty Cookie Object: Per MLQ News and BleepingComputer, developer Vates VMS published advisory VSA-2026-062 and shipped the Vates 6.10.0 and 6.9.1 patch releases after discovering active exploitation of a cookie authentication bypass. Sending the cookie authenticationToken=j:{} triggers an empty authenticationToken cookie bypass. The parser converts j:{} into an empty object ({}), and the token lookup treats that as an unfiltered query. It returns the first stored token in the database and logs the attacker in as that token’s owner, no password required.
• Chained Unpatched VM-Import Zero-Day Leading to XCP-ng root Takeover: As reported by SecurityWeek on November 11, 2026, Vates warned that the same attacker is chaining the gained admin privileges with a second, previously unknown zero-day in VM imports. That flaw allows malicious VM imports to compromise the hypervisor, resulting in full XCP-ng virtualization host takeover as root. VSA-2026-062 is fixed in 6.10.0 (latest) and 6.9.1 (stable), but a fix for the VM-import zero-day is still in development.
• Unlogged Access and Verified Attacker IOC (91.211.251.112:8001 and Tor): Vates warned via SecurityWeek and The Hacker News that Xen Orchestra does not log unauthorized access through VSA-2026-062. The observed attacker initially operated from 91[.]211[.]251[.]112:8001 (91.211.251.112:8001) and via the Tor network.
• Mandatory Full Reinstallation for Compromised Hosts: Vates advised via SecurityWeek that confirmed compromises require a full reinstallation, because cleanup alone cannot guarantee the removal of every hypervisor backdoor.

Reported or Unconfirmed Claims

• CVE Assignment Status: Per SecurityWeek, no CVE IDs or CVSS scores had been assigned to VSA-2026-062 or the VM-import zero-day as of November 12, 2026.
• Victim Scope and Attribution: Vates has not named victims or attributed the attacks, and it warns that other threat actors using different infrastructure cannot be ruled out.

The table below lays out the confirmed sequence of the VSA-2026-062 and XCP-ng zero-day disclosures.

Facts at a Glance

The table below summarizes the verified technical attributes of VSA-2026-062 and the chained VM-import zero-day.

Affected and Fixed Versions

The table below maps affected Vates components, fixed versions, and workarounds per MLQ News and SecurityWeek.

Technical Attack Chain

1. Root Cause of the Xen Orchestra Exploit and XCP-ng Takeover

Per Vates VMS details reported by MLQ News and SecurityWeek, the Xen Orchestra VSA-2026-062 exploit chains an unauthenticated JSON cookie object injection with an administrative VM-import flaw. The sequence runs in three steps:

• Initial Access via Empty JSON Cookie (MITRE ATT&CK T1190, Exploit Public-Facing Application): In Express middleware (cookie-parser), cookies prefixed with j: are parsed as JSON objects. Send authenticationToken=j:{} and Xen Orchestra parses the cookie into an empty object ({}).
• Unfiltered Token Lookup (T1078, Valid Accounts): The lookup lacks string-type validation, so the empty authenticationToken cookie bypass treats {} as an unfiltered query. It returns the first stored token in the database, typically the primary admin, and logs the attacker in without a password and without generating a login log.
• Hypervisor root Takeover via VM-Import Zero-Day (T1068): With the hijacked admin session, the attacker triggers an unpatched VM import zero-day through a malicious VM import. That executes arbitrary code across pools and delivers XCP-ng virtualization host takeover as root.

Why Patching Alone May Not Be Enough

Updating closes the front door. It does not undo what may already have happened, and three problems explain why.

• The Chained VM-Import Zero-Day Remains Unpatched: Updating to 6.10.0 or 6.9.1 stops unauthenticated entry. But because the unpatched VM import zero-day still awaits a vendor fix, any attacker who stole admin credentials or tokens before you patched can still compromise XCP-ng hosts.
• Bypassed Logins Are Not Logged: Because VSA-2026-062 reuses an existing database token, Vates warned via SecurityWeek that unauthorized logins leave no Xen Orchestra auth logs at all.
• Hypervisor Backdoors Require Full Reinstallation: Once an attacker gains root on XCP-ng dom0, Vates states that only a full reinstallation guarantees the removal of every backdoor.

CyberInfos Analyst Insight

• CyberInfos Assesses That authenticationToken=j:{} Is a Classic Node.js Type-Confusion Trap: Automatic deserialization of j:{} into {} turns a token lookup into a wildcard query that returns the first admin token in the database.
• From a Defensive Perspective, Chaining a Pre-Auth Bypass With a Hypervisor Zero-Day Signals a Sophisticated Actor: The operator at 91.211.251.112:8001 arrived with a weaponized VM-import zero-day, ready to escalate from web console access to root XCP-ng virtualization host takeover.
• Virtualization Consoles Belong Behind Zero-Trust Access: This week’s Citrix XenServer patches per SecurityWeek and N-able N-central’s Able2Shell crisis per Dark Reading point the same way. Hypervisor managers must never sit on the open internet.

Indicators of Compromise and Hunting Telemetry

Xen Orchestra does not log VSA-2026-062 logins, so defenders have to look elsewhere: reverse-proxy and WAF logs, firewall flows, and XCP-ng dom0 telemetry, per SecurityWeek. Finding none of these campaign-specific IOCs does not rule out compromise.

The table below lists every verified indicator disclosed by Vates VMS.

/* Splunk SPL (Draft for testing, not production-validated):
   Hunt reverse-proxy, WAF, or firewall logs for VSA-2026-062 empty authenticationToken cookie or attacker IP 91.211.251.112 */
(index=web OR index=proxy OR index=waf OR index=firewall)
("authenticationToken=j:{}" OR "authenticationToken=j%3A%7B%7D" OR "authenticationToken=j:%7B%7D" OR src_ip="91.211.251.112" OR dest_ip="91.211.251.112")
| stats count earliest(_time) as first_seen latest(_time) as last_seen values(http_user_agent) as user_agents values(uri_path) as paths by src_ip, dest_ip, status
| sort - count

// Microsoft Sentinel / Defender KQL (Draft for testing, not production-validated):
// Hunt for network connections involving 91.211.251.112 or port 8001 on Xen Orchestra and XCP-ng management segments
CommonSecurityLog
| where TimeGenerated >= ago(30d)
| where SourceIP == "91.211.251.112" or DestinationIP == "91.211.251.112" or RequestContext has_any ("authenticationToken=j:{}", "authenticationToken=j%3A%7B%7D")
| project TimeGenerated, DeviceVendor, SourceIP, DestinationIP, DestinationPort, RequestURL, RequestContext, DeviceAction
| order by TimeGenerated desc

Recommended Actions

Work through these numbered steps across three phases, per Vates guidance reported by SecurityWeek and MLQ News.

Immediate Actions (0 to 24 Hours)

1. Apply the Vates 6.10.0 and 6.9.1 Patch and Isolate Consoles: Deploy the Vates 6.10.0 and 6.9.1 patch across all Xen Orchestra (XO / XOA) instances now, and move every management console behind a dedicated VPN or private network.
2. Block authenticationToken=j:{} in WAF and Block 91.211.251.112: Add a WAF or reverse-proxy rule that rejects authenticationToken=j:{} (and j%3A%7B%7D), and block traffic involving 91.211.251.112:8001 and Tor exit nodes.
3. Revoke Stored Tokens and Rotate All Credentials: Flush all stored tokens in Xen Orchestra, then rotate every XO admin password, API token, and XCP-ng root password.

Short-Term Actions (Within 7 Days)

4. Audit XCP-ng Hosts and Reinstall if Compromised: Inspect XCP-ng dom0 logs (/var/log/xensource.log, /var/log/audit/audit.log, SSH authorized_keys) for unauthorized vm-import tasks or root access. Fully reinstall any compromised host.
5. Restrict Admin VM-Import Access Until the Second Patch Ships: Limit admin roles in Xen Orchestra to essential personnel, and monitor every VM import until Vates patches the VM-import zero-day.

Long-Term Actions (Architecture)

6. Enforce Out-of-Band Management Segmentation and Immutable Backups: Place XCP-ng dom0 and Xen Orchestra on an isolated bastion network with hardware MFA, and keep offline VM backups.

Global Regulatory and Compliance Implications (USA, UK, Australia, EU, Canada, India)

Regulatory duties apply only when an organization is in scope and suffers a reportable incident. The table below summarizes verified compliance rules across six jurisdictions as of November 12, 2026.

This summary supports operational readiness and is not legal advice.

Frequently Asked Questions (FAQ)

What is the Xen Orchestra VSA-2026-062 exploit and who is affected?

The Xen Orchestra VSA-2026-062 exploit targets a critical authentication bypass in Vates VMS’s Xen Orchestra and Xen Orchestra Appliance virtualization management platform, in versions before 6.9.1 and 6.10.0. Attackers are actively exploiting the flaw in the wild to gain unauthenticated administrator access and take over managed XCP-ng virtualization servers, per BleepingComputer.

How does the attacker hijack hypervisors after bypassing Xen Orchestra login?

According to Vates’s advisory reported by SecurityWeek and MLQ News, once the attacker gains administrator privileges in Xen Orchestra via VSA-2026-062, they chain a second zero-day vulnerability involving malicious VM imports. That lets them execute arbitrary code across managed pools and achieve XCP-ng virtualization host takeover as root.

How does the empty cookie authentication bypass work technically?

As detailed by MLQ News, the empty authenticationToken cookie bypass occurs when an attacker sends a cookie of authenticationToken=j:{}. Xen Orchestra parses j:{} into an empty object, and the token lookup treats it as an unfiltered query. The result: the first stored token in the database comes back, and the attacker is logged in without a password or a log entry.

Is the chained VM-import zero-day patched in Xen Orchestra 6.10.0 and 6.9.1?

No. The unpatched VM import zero-day was still awaiting a fix from Vates as of November 11 to 12, 2026, according to SecurityWeek. The flaw does require administrator privileges, though. Upgrading to 6.10.0 or 6.9.1 and revoking stored tokens blocks unauthenticated attackers from reaching the vulnerable import function.

What should administrators do after applying the Vates security update?

After installing the Vates 6.10.0 and 6.9.1 patch, administrators must place Xen Orchestra behind a private network, block authenticationToken=j:{} in a WAF rule, block 91.211.251.112:8001 and Tor traffic, and rotate all credentials. They must also fully reinstall any compromised instance, because cleanup alone cannot guarantee backdoor removal, per SecurityWeek.

Final Thoughts

This in-the-wild campaign shows how quickly a cookie-deserialization flaw in a virtualization console can become full hypervisor root compromise. The active campaign pairing the Xen Orchestra VSA-2026-062 exploit with a post-authentication VM-import zero-day makes the point plainly. VSA-2026-062 leaves no internal login logs, and the chained VM-import bug still awaits a patch. Leaving Xen Orchestra reachable from untrusted networks puts your entire virtualized infrastructure at risk.

Update all Xen Orchestra instances immediately, enforce WAF rules that block empty token objects, isolate management consoles behind a VPN, and rebuild any host that shows unauthorized VM imports or traffic involving 91.211.251.112. Share your XCP-ng hardening practices in the comments below, and subscribe to CyberInfos.in for daily verified vulnerability and threat intelligence.