AI News
Claude Found Two Critical Xen Bugs That Let One Virtual Machine Read Another's Memory
The Xen Project disclosed XSA-523 on November 3: two flaws in grant copy, the operation Xen uses to copy data between virtual machines, that let a malicious guest read and write the memory of other VMs on the same host. The advisory's impact statement is short and absolute: a malicious guest can read and write arbitrary memory belonging to other domains, including Dom0. Every Xen version from 4.6 onward is affected, and there is no workaround. The only fix is to install the patched build and reboot the host.
Dom0 is the privileged control domain that manages every other VM on a Xen host. If a guest can write Dom0 memory, the isolation between tenants on that host is gone. That is what makes this advisory different from an ordinary privilege bug: it breaks the promise a hypervisor exists to keep.
The two bugs
Both flaws sit in how Xen handles batches of copy operations. To speed up batches, Xen reuses checks it has already made, and in some cases it skipped a check it needed. CVE-2026-102703 is the first: frame numbers and grant references could be mixed up in cached grant-copy state, so within a batch Xen could reuse an already-validated mapping when the next operation named its memory differently. A guest that controls the arguments to its own grant copy hypercalls can get Xen to copy to or from memory that belongs to other domains.
CVE-2026-102704 is the second: copying by frame number, rather than grant reference, is permitted only when operating on the caller's own memory, but the check enforcing that restriction was in the wrong place. Together, the two logic errors turn a performance optimization into a cross-VM read and write primitive.
Who is affected, and what to do
All Xen versions from 4.6 onward are vulnerable. Xen 4.5 and earlier are not. That covers self-run Xen hosts, XCP-ng pools, other Xen-based products until their makers ship the patches, hosting companies that sell Xen VMs, and Qubes OS desktops. The advisory says there is no known mitigation, and the fix is a patched hypervisor followed by a reboot, since a hypervisor only changes when the host restarts.
The patches are not universal. Upstream patches cover xen-unstable down to Xen 4.17.x, and the advisory lists no patch for Xen 4.6 to 4.16. Support for 4.16 ended in December 2024, so operators on those versions must upgrade or accept unmitigated exposure. XCP-ng 8.3 users should apply the November 3 update, xen-4.17.7-4.2.xcpng8.3, and reboot each host.
How Claude found it
The disclosure is notable for who found the flaws. The Xen Project formally credits Anthropic, using its Claude AI model, with the discovery, with validation by Stephan Lipp of Ada Logics. The CodeAnt AI Security Research Team reported the same issue independently. The patch commits even carry a trailing line reading Assisted-by: Claude.
It has been reported as the first time a commercial AI system has been publicly credited with finding critical flaws in an upstream hypervisor project. That framing is the reporters', not the advisory's, but the credit itself is in the advisory. The same capability that found these bugs is the capability defenders worry about, and this advisory is now the clearest public example of it working on the defensive side.
How bad is it, really
There is no known exploitation of either flaw, and neither CVE appears in the US CISA Known Exploited Vulnerabilities catalog as of November 4. The advisory does not report attacks, and it does not say what access inside a VM an attacker needs. That is genuinely reassuring, and it is also the limit of the reassurance: the flaws are logic errors in a mechanism every Xen guest can reach, and the only fix is patching.
The severity scores tell a split story. Xen has not published a CVSS score. NVD now shows a secondary CVSS 3.1 score from CISA-ADP of 4.4 Medium for both CVEs, updated November 5. Rescana and Vates, by contrast, rate the issue Critical. The gap is not a contradiction: the CVSS figure measures the flaw in isolation, while the Critical ratings weigh the Dom0 reach, the absence of any mitigation, and the breadth of affected versions. Operators should patch on the Critical reading, not the Medium one. XSA-523 is separate from XSA-500, an earlier grant-copy type confusion Xen published on July 28, 2026, and it needs its own patches.