Vulnerabilities

Xen XSA-523: a guest can read and write other VMs' memory

By Yaali. November 7, 2026, 6 min read, Vulnerabilities, Patching, Cloud.

Two grant copy flaws in Xen 4.6 and later let a malicious guest reach other VMs and dom0. Fixed builds for XCP-ng, Debian and Qubes, and how to verify.

The Xen Project published advisory XSA-523 on November 3, covering two bugs in the hypervisor's grant copy code, tracked as CVE-2026-102703 and CVE-2026-102704. In the advisory's words, "a malicious guest can read and write arbitrary memory, belonging to other domains, including Dom0". Dom0 is the privileged control domain that manages every other VM on the host, so write access to it amounts to control of the whole machine.

Every Xen release from 4.6 onwards is vulnerable; 4.5 and earlier are not. The advisory lists no mitigation, so the fix is a patched hypervisor and a host reboot. You are affected if you run XCP-ng, Debian's Xen packages, Qubes OS or your own Xen build, and the risk is highest where guests run code you do not control: hosting, VDI, CI runners and lab environments. Vates rates it Critical for XCP-ng 8.3.

How it works

Xen guests share memory through grant tables. A guest that wants another domain to touch one of its pages publishes a grant reference for it, and the hypervisor checks that grant before allowing access. Paravirtual drivers, such as the network and disk backends in dom0, rely on this to move data in and out of guests. One of the operations is grant copy: a hypercall that asks Xen itself to copy bytes between two pages.

Each side of a copy is named in one of two ways. A grant reference points at another domain's page and is checked against that domain's grants. A raw frame number skips the grant check, so Xen permits it only when the page belongs to the caller. Callers usually send copies in batches, often many small copies that hit the same page. To save work, Xen keeps the page it validated for the previous element and reuses it when the next element points at the same place.

The advisory says the rules for when that cached page must be validated again were wrong in two places:

CVE-2026-102703. The comparison that decides whether the cache matches could mistake a frame number for a grant reference. The patch describes a grant reference left over from an earlier element in the batch being taken for a frame number in a later one.
CVE-2026-102704. The check that only the caller's own memory may be named by frame number sat in the wrong place. According to the patch, it ran only when Xen looked up the domains for an element, which it does not do for every element in a batch, so later elements could skip it.

Either way, a guest can get Xen to copy to or from a page it has no right to, and the hypervisor does the copying with its own privileges. Both fixes are in Xen's common grant table code (xen/common/grant_table.c), and the advisory names no guest type or CPU architecture as exempt.

What attackers are doing

None of the advisories from the Xen Project, Vates, Debian or Qubes reports exploitation in the wild, and no indicators of compromise have been published. The advisory credits Anthropic, which found the bugs using Claude, with validation by Stephan Lipp of Ada Logics. The CodeAnt AI Security Research Team reported the same issues independently.

This is the second grant copy advisory of 2026. XSA-500, a type confusion in grant copy, went out on July 28 and was fixed in XCP-ng and Qubes at the time. Anyone who patched for XSA-500 still needs this update.

What to do

Patch the hypervisor and boot into it. Installing the package alone changes nothing, because the running Xen stays in memory until the host restarts.

XCP-ng 8.3. The fix shipped on November 3 as xen-4.17.7-4.2.xcpng8.3 (Vates advisory VSA-2026-055), synced with XenServer's 4.17.7-4 release. Use Rolling Pool Update in Xen Orchestra (pool view, Patches tab), which needs two or more hosts and shared storage. From the command line, start with the pool master: xe host-disable uuid=<uuid>, xe host-evacuate uuid=<uuid>, yum update, check xe task-list is empty, then reboot. On November 4 Vates also shipped a dom0 kernel fix for CVE-2026-98432 (VSA-2026-056) that needs its own reboot. Updates are cumulative, so a host patched today picks up both in one reboot.
Debian 13 (trixie). DSA-6610-1 on November 4 fixes it in xen 4.20.4+63-g7abfd2bce2-0+deb13u1. Run apt update && apt upgrade, then reboot.
Debian 12 (bookworm). The security tracker lists the LTS update DLA-4881-1, xen 4.17.7+13-g2445b30a44-0+deb12u1. The tracker still marks forky (testing) as vulnerable; sid is fixed.
Qubes OS. QSB-121 says all supported releases and configurations are affected. For Qubes 4.3 the fix is Xen 4.19.6-3 in dom0, now in the security-testing repository and due to reach the current repository within about two weeks. To install it now, run sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing in dom0, then restart. Anti Evil Maid users must reseal their passphrase, because the new Xen binaries change PCR 18 and 19.
Your own builds. Apply xsa523-1.patch and xsa523-2.patch for xen-unstable down to 4.19.x, or xsa523-4.18-1.patch and xsa523-4.18-2.patch for 4.18.x and 4.17.x. The Xen Project prepares patches against the stable branches, so update to the tip of yours first; they may not apply cleanly to a release tarball.

To confirm what is running, xl info reports the live hypervisor in xen_version (or xen_major, xen_minor and xen_extra). That number does not carry a distribution's patch revision, so also compare the host's boot time from uptime -s with when the package went in: rpm -q --last xen-hypervisor on XCP-ng, or grep xen-hypervisor /var/log/dpkg.log on Debian. A host that booted before the update is still running the vulnerable code.

If you cannot reboot today, there is no setting to turn off. Move guests you do not trust to patched hosts, and do not start new untrusted guests on unpatched ones. Since there is nothing to search for, assume that a hostile guest on an unpatched host could have read dom0 memory, and rotate the secrets dom0 holds there: pool and management credentials, storage and backup keys, and API tokens.

Hypervisor reboots need a fast path

Hosts that only reboot in a quarterly window carry bugs like this for months, and XSA-500 and XSA-523 arrived three months apart. Keep enough spare capacity and shared storage that a pool can be drained and rebooted host by host within a day, and track the running Xen version per host so you can see which ones still need it.

If you run Xen or XCP-ng pools and want help planning the rollout or reviewing how guests are isolated, our platform and cloud engineering and safeguarding and hardening teams do this work. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would handle it.

Sources: Xen Security Advisory XSA-523, XSA-523 patch 1, XSA-523 patch 2, Vates VSA-2026-055, XCP-ng November 2026 updates #1, XCP-ng November 2026 updates #2, XCP-ng update guide, Debian DSA-6610-1, Debian tracker CVE-2026-102703, Debian tracker CVE-2026-102704, Debian tracker DLA-4881-1, Qubes QSB-121, Qubes QSB-116, The Hacker News.