Xen hosts: one malicious VM can read and write every other VM’s memory. Patch the hypervisor and reboot

The Xen Project has fixed two bugs that let a malicious virtual machine read and write the memory of the other VMs on the same host, including dom0, the VM that manages the rest. XCP-ng, which packages Xen for companies, put it plainly: a single compromised guest can take over the whole host.

There is no workaround. The fix is a patched hypervisor, and a hypervisor only changes when the host reboots.

On Xen, one compromised VM can read and write the memory of every other VM on the host. The only fix is a patched hypervisor and a reboot.

The 5-Minute Cyber Brief

Don’t Miss the Policy Changes That Affect Security Decisions

Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.

Email addressSend me tomorrow’s brief

By subscribing you agree to our Privacy Policy.

Free. Weekday mornings. 5 minutes or less.

Two Xen bugs let one VM reach every other VM’s memory

Xen Security Advisory XSA-523, published November 3, covers CVE-2026-102703 and CVE-2026-102704 in grant copy, the operation Xen uses to copy data between VMs. To speed up batches of copies, Xen reuses checks it has already made, and in some cases it skipped a check it needed. One bug mixes up frame numbers and grant references. The other misplaces the check that limits copying by frame number to a VM’s own memory.

The Xen Project credits Anthropic, using its Claude model, with finding the flaws, and Stephan Lipp of Ada Logics with validating them. The CodeAnt AI Security Research Team reported the same issue independently.

Every Xen host from 4.6 on, including XCP-ng and Qubes

All Xen versions from 4.6 onward are vulnerable. 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 risk is highest wherever a host runs VMs for more than one customer or team.

The advisory does not report attacks or say what access inside a VM an attacker needs. XCP-ng’s maker Vates rates the impact critical.

Patch the hypervisor and plan the host reboots

• XCP-ng 8.3: apply the November 3 update (xen-4.17.7-4.2.xcpng8.3) and reboot each host. A second XCP-ng update for a Linux kernel TCP bug followed, so plan for both.
• Qubes OS 4.3: install the Xen 4.19.6-3 packages in dom0 when they reach your repository, then restart.
• Self-built Xen: apply the XSA-523 patches (xsa523-1 and -2 for 4.19 and unstable, the 4.18 set for 4.18 and 4.17) on the tip of your stable branch. Xen 4.16 and older get no patch.
• Ask your hosting or VPS provider whether its Xen hosts have the XSA-523 fix and when they reboot.

Details

• CVE-2026-102703: frame numbers and grant references could be mixed up in cached grant copy state.
• CVE-2026-102704: misplaced check on copying by frame number, allowed only on the caller’s own memory.
• Affected: Xen 4.6 and later. 4.5 and earlier not vulnerable. No known mitigation (XSA-523).
• Fixes: XSA-523 patches; XCP-ng 8.3 xen-4.17.7-4.2.xcpng8.3 (VSA-2026-055, November 3). Debian’s tracker listed xen in bookworm, trixie and forky as vulnerable on November 4, per The Hacker News.

Hunt / verify

• On each host, run xl info | grep xen_version (or check the XCP-ng update list) and list hosts that have not rebooted since November 3.
• Review which tenants or teams share a host with sensitive VMs, and move the sensitive ones to patched hosts first.

Source: Xen XSA-523; XCP-ng November 3 update

Sources

• Xen Project: XSA-523, arbitrary read/write via grant copy (November 3, 2026)
• oss-security: Xen Security Advisory 523 v2 (CVE-2026-102703, CVE-2026-102704)
• XCP-ng: November 2026 Security and Maintenance Updates #1 for XCP-ng 8.3 LTS
• The Hacker News: Xen Hypervisor Flaws Let One Malicious VM Read and Write Any Other VM’s Memory
• CVE.org: CVE-2026-102703

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].