Two flaws in the Xen hypervisor allow a malicious guest virtual machine (VM) to read and write the memory of other VMs on the same host, including dom0.
Dom0 is the VM that, by default, has full permissions and manages the others. Patches are out, and there is no known mitigation, the Xen Project said in an advisory on November 3.
All Xen versions from 4.6 onward are vulnerable, while 4.5 and earlier are not. The flaws are tracked as CVE-2026-102703 and CVE-2026-102704, under Xen advisory XSA-523.
The Xen Project credited AI company Anthropic with finding the flaws using its Claude model. Stephan Lipp of Ada Logics then validated the finding, and the CodeAnt AI Security Research Team later independently reported the same issue.
The flaws are in grant copy, the operation Xen uses to copy data between VMs. Each VM tells Xen which of its memory pages other VMs may use, and Xen checks those permissions.
To save time on a batch of copies within the same memory page, Xen reuses checks it has already made. In some cases, it did not check again when it should have. That mistake is what lets a malicious guest read and write memory it does not own.
XCP-ng, an open-source virtualization platform built around Xen, said in its update notes that “a single compromised guest can break out of its isolation and take over the whole host.”
Xen’s advisory does not mention any attacks that exploit the flaws or specify what access within the VM an attacker needs.
Qubes OS is a security-focused desktop operating system that keeps software in separate Xen-based compartments called qubes. A bulletin said that every supported release and configuration is affected. Its fix is for Qubes 4.3, the only release it still supports.
Because every Xen version from 4.6 on is vulnerable, other products built on those versions are affected until their makers add the XSA-523 patches. As of November 4, Debian’s security tracker listed the xen package in its bookworm, trixie, and forky releases as vulnerable, and in sid as fixed.
Fixes and Restarts by Platform
These are the fixes published so far:
- Xen source: the advisory has patches for xen-unstable to Xen 4.19.x, and for Xen 4.18.x to 4.17.x.
- Xen 4.6 to 4.16: the advisory has no patch for these versions. Xen 4.16’s security support ended on December 2, 2024.
- XCP-ng 8.3: xen-4.17.7-4.2.xcpng8.3, released November 3. Hosts must be rebooted. Vates, which backs XCP-ng, rates the impact as Critical.
- Qubes OS 4.3: Xen packages 4.19.6-3 in dom0. Dom0 must be restarted, and Anti Evil Maid users must reseal their secret passphrase because the new Xen binaries change PCR18 and PCR19.
Qubes told users on November 3 to keep installing updates as normal. The fixed packages were then in its security-testing repository, due to move to the stable one over the next two weeks after community testing.
XSA-523 is separate from XSA-500, an earlier grant copy flaw that Xen disclosed on July 28, and it has its own patches.
Update: CodeAnt Runs Code in the Dom0 Kernel From a Guest VM
On November 4, CodeAnt AI published a write-up on what it calls Xenbleed. Its researcher Hemanshu Baviskar found the bug independently, and the team reported a working guest-to-dom0 escape on XenServer 9 to Xen on October 13. Xen replied the next day that the issue was already known and a fix was in progress.
In CodeAnt’s test, a guest VM found a marker value in dom0’s memory and changed it. The team then used that access to run a short, reversible set of instructions in the dom0 Linux kernel.
That proof used one exact XenServer dom0 kernel image and a single CPU, and the team did not measure how reliable it is on multi-CPU systems. It reached the dom0 kernel, not Xen’s own code.
The attacker starts with kernel-level control inside a guest, according to CodeAnt. Both a PVH guest and an HVM guest on x86 could reach the vulnerable code.
The chain used CVE-2026-102704, and the team did not test CVE-2026-102703 separately. CodeAnt’s own CVSS assessment for both CVEs is 9.3 under version 3.1 and 9.4 under version 4.0.
CodeAnt traced the bug to a grant copy performance change committed on January 29, 2015. It said the XSA-523 patches fix both incomplete cache checks.
