The Xen Project has disclosed two flaws, CVE-2026-102703 and CVE-2026-102704, that let a malicious virtual machine read and write the memory of other guests on the same host, including dom0. Advisory XSA-523 says no mitigation is known, and downstream projects XCP-ng, Qubes OS and Citrix XenServer have published their own warnings.
XSA-523 Describes Missing Permission Checks in Grant Copy
The advisory, published on 3 November, covers a defect in grant copy, the operation Xen uses to copy data between virtual machines. Xen reuses permission checks across a batch of copies that fall within the same memory page. In some cases it failed to check again when it should have, which allowed a guest to access memory it had no right to touch.
A guest that exploits the bug can read and write memory belonging to other virtual machines on the host. That includes dom0, the control domain, which holds full permissions over the hypervisor’s guests. All Xen versions from 4.6 onward are affected; version 4.5 and earlier are not.
Anthropic’s Claude Model Found the Bugs
The advisory credits Anthropic with discovering the flaws using its Claude model. Stephan Lipp of Ada Logics validated the finding, and the CodeAnt AI Security Research Team independently reported the same issues. The advisory offers no exploitation reports and does not state what level of guest access an attacker needs.
Downstream Xen Distributions Confirm Guest-to-Host Escape Risk
Projects built on Xen published their assessments within a day of the advisory. Their statements are more specific than the upstream text about what an attacker gains.
XCP-ng and Qubes OS Warn of Full Host Takeover
XCP-ng says a single compromised guest “can break out of its isolation and take over the whole host.” Qubes OS states that every supported release and configuration is affected, and its fix applies to Qubes 4.3.
Citrix Lists CVE-2026-102703 as a Privileged-Guest Breakout
Citrix’s bulletin of 4 November lists CVE-2026-102703 in XenServer as a guest-to-host breakout available to a privileged guest user. That wording narrows the access requirement for XenServer deployments compared with the upstream advisory, which is silent on the point.
Multi-Tenant Xen Hosts Carry the Highest Exposure From the Xen Memory Flaws
Virtual machine isolation is the security boundary that multi-tenant hosting and cloud platforms sell. A flaw that lets one guest read and write another’s memory removes that boundary on any unpatched Xen host, and reaching dom0 would give an attacker control over every other guest on the machine. No attacks have been reported so far.
Because the defect lies in the hypervisor’s copy operation, updating guest operating systems does not address it; the fix has to be applied at the Xen layer on each host. The advisory’s silence on exploitation and on the guest access an attacker needs leaves defenders with no threat model beyond the worst case the downstream projects describe.
Xen has released patches for the two flaws, but there is no workaround for hosts that cannot apply them. Operators of Xen-based platforms therefore depend entirely on the fixed builds from the Xen Project or from their distribution vendor.
The disclosure also places an AI model at the origin of a hypervisor vulnerability report. Anthropic’s credit alongside human validators and a separate research team that arrived at the same bugs independently shows that the code in question was reachable by more than one discovery method at roughly the same time, which narrows the window in which a defender could assume the flaws were unknown to others.
The Qubes OS statement that every supported release and configuration is affected, with the fix landing in Qubes 4.3, means users of that desktop system have no unaffected setup to fall back on.
