Xen XSA-523 (CVE-2026-102703/102704): Grant-Copy Flaws Let a Malicious VM Read and Write Any Other Domain's Memory — Found by Anthropic Using Claude
Two grant-copy validation bugs in every Xen release since 4.6 let a malicious guest read and write the memory of other VMs and Dom0, with no mitigation other than patching.
What Happened
The Xen Project has published Xen Security Advisory 523 (XSA-523). It covers two related flaws in the hypervisor's grant-copy mechanism, tracked as CVE-2026-102703 and CVE-2026-102704. The advisory states the impact directly: "A malicious guest can read and write arbitrary memory, belonging to other domains, including Dom0."
The advisory went public on 3 November 2026. In a multi-tenant virtualisation host, this is about as bad as hypervisor bugs get. One untrusted virtual machine can reach into its neighbours and into the privileged control domain that manages the whole host.
The credits stand out too. According to the advisory, the issue "was discovered by Anthropic using Claude, then validated by Stephan Lipp of Ada Logics." The CodeAnt AI Security Research Team reported it independently. So two separate AI-assisted research efforts found the same deep memory-safety logic bug in one of the most heavily reviewed open-source hypervisors.
Technical Details
Grant tables are how Xen guests share memory with one another and with Dom0. Paravirtualised drivers depend on them for disk and network I/O. The grant copy operation lets a domain ask the hypervisor to copy data between pages. Each page is identified either by a grant reference, which another domain has explicitly shared, or by a raw frame number.
There is a strict rule for frame numbers. The advisory says copying by frame number "is permitted only when operating on the caller's own memory."
To save time, Xen processes grant copies in batches. When several operations in a batch touch adjacent ranges of the same page, Xen reuses cached data it has already validated rather than checking every time. XSA-523 says the conditions for re-validating that cached data were wrong in some cases:
- CVE-2026-102703: frame numbers and grant references could be confused with each other. Something validated as one kind of reference could be treated as the other.
- CVE-2026-102704: the check that limits frame-number copies to the caller's own memory sat in the wrong place, so a crafted sequence could get past it.
A guest that builds a suitable batch can therefore point copy operations at memory it does not own. That gives it arbitrary read and write access across domain boundaries, including Dom0.
Who Is Affected
The advisory states that "all Xen versions from 4.6 onwards are vulnerable." Xen 4.5 and earlier are not affected. That window covers roughly a decade of releases, so the exposure is broad:
- Hosting and cloud providers that run Xen-based multi-tenant infrastructure
- XCP-ng and other Xen-based virtualisation platforms
- Qubes OS, whose whole security model rests on Xen keeping qubes isolated from each other
- Embedded and automotive systems built on Xen
The attacker must already control code inside a guest, for example a customer VM on a shared host or a compromised qube. Remote attackers cannot trigger it directly. That precondition is exactly the threat a hypervisor exists to contain.
Patch Status
The Xen Project has released patches:
- xen-unstable and Xen 4.19.x: xsa523-1.patch and xsa523-2.patch
- Xen 4.18.x and 4.17.x: xsa523-4.18-1.patch and xsa523-4.18-2.patch
The advisory notes that the stable-branch patches may not apply cleanly to the latest release tarballs. It encourages downstream builders to move to the tip of the relevant stable branch first. Versions between 4.6 and 4.16 are vulnerable but out of security support and receive no patch.
The advisory is blunt about workarounds: "There is no known mitigation." Downstream projects have started shipping fixes. XCP-ng released updated Xen packages for 8.3, and Qubes OS issued its own bulletin, with the fixed package moving from the security-testing repository to stable.
No exploitation in the wild had been reported when the advisory was published.
What To Do Now
- Inventory Xen hosts, including appliances and platforms that embed Xen without saying so prominently.
- Apply your distribution's or vendor's XSA-523 update and reboot the hypervisor. A hypervisor fix only takes effect after the host restarts on the new build.
- Plan migrations off Xen 4.16 and older. Those branches get no fix, and there is no mitigation.
- Qubes users should install updates through the Qubes update tool once the patched Xen package reaches their repository, then restart.
- Providers should treat any host running untrusted tenants as top priority, and review guest-to-Dom0 isolation assumptions in their incident-response plans.
On a Xen host you can confirm the running hypervisor version with:
xl info | grep -E 'xen_(major|minor|extra)'Why It Matters
Hypervisor isolation is the foundation many organisations build on without thinking about it. A cross-domain read/write primitive breaks that foundation. It turns "an attacker owns one VM" into "an attacker can own every VM on the box."
The discovery story matters as well. Grant tables are old, heavily scrutinised code, yet the flaw sat there for about ten years. It took a reasoning-heavy pass over batched validation logic to find it. That an AI model found it first, and that a second AI-driven team found it independently, fits a pattern seen across recent advisories: AI-assisted auditing is now finding subtle logic bugs in mature infrastructure code. Defenders should expect more advisories like this, sooner, and plan patch capacity for low-level components they once treated as stable.
