Skip to content
Rush Commerce
Software & Dev3 min read

Xen XSA-523: Claude-found bug lets one VM read any other VM

Xen XSA-523 lets a malicious guest read and write other VMs' memory, dom0 included. Anthropic's Claude found it. Patch and reboot hosts, or ask your VPS host.

The wall between virtual machines on a Xen host had a hole in it for over a decade. Xen advisory XSA-523 covers two grant-copy bugs that let a malicious guest VM read and write the memory of other VMs on the same host, including dom0, the control domain. The Xen Project credits Anthropic, using Claude, with the discovery. Every Xen release from 4.6 on is affected, and there is no workaround. The fix is a patched hypervisor and a reboot.

What actually happened

The Xen Project published XSA-523 on November 3, tracked as CVE-2026-102703 and CVE-2026-102704. Per the advisory:

  • The bug. Grant copy is how Xen moves data between VMs. To go faster, Xen caches checks it already ran for nearby copies. In some cases it didn't re-check when it should have. One flaw mixes up frame numbers and grant references. The other misplaces the check that limits copy-by-frame-number to the caller's own memory.
  • Impact. "A malicious guest can read and write arbitrary memory, belonging to other domains, including Dom0."
  • Scope. Xen 4.6 and later. Patches cover Xen 4.17 through 4.19 and unstable. Releases 4.6 to 4.16 get no patch here.
  • Mitigation. None. Patch the hypervisor.
  • Credit. Discovered by Anthropic using Claude, validated by Stephan Lipp of Ada Logics, and independently reported by the CodeAnt AI Security Research Team.

The Hacker News reports that XCP-ng shipped a fix on November 3 that needs a host reboot, and Vates rates the impact critical. Qubes OS 4.3 has fixed packages that need a dom0 restart. CodeAnt says it built a working guest-to-dom0 escape on XenServer 9, starting from kernel-level control inside a guest. Xen's advisory reports no attacks in the wild.

Why the Xen XSA-523 fix matters for your business

You may run Xen without knowing it. Some VPS and cloud providers use it, and so do XCP-ng and XenServer setups in small server rooms. On a shared host, your VM's neighbor is the attacker this bug is built for.

Here's the short list:

  1. Self-host on XCP-ng, XenServer or raw Xen? Install the XSA-523 update and schedule the reboot. A patch that isn't running yet doesn't protect you.
  2. On a VPS? Ask your provider two questions: do you run Xen, and when did you apply XSA-523? Get the answer in writing.
  3. Still on Xen 4.16 or older? You're past security support. Plan the upgrade now.

Also note who found it. An AI model found a bug in the grant-copy fast path, code CodeAnt traces back to 2015. Attackers have access to the same class of tools. Patch windows are getting shorter, and "nobody has found it in ten years" is no longer a safety argument.

Key takeaways

  • XSA-523 lets a malicious Xen guest read and write other VMs' memory, dom0 included
  • All Xen versions from 4.6 on are affected; there is no mitigation, only patches
  • Anthropic found it using Claude; CodeAnt reported it independently and demonstrated an escape
  • XCP-ng and Qubes fixes need a host or dom0 restart to take effect
  • On a VPS, ask your host if they run Xen and when they applied XSA-523

Not sure what your servers actually run on? We audit hosting stacks for small businesses, from the hypervisor up, and set up patch schedules that don't depend on someone remembering. Ask us to check your setup, or see what we build.

Sources: Xen Project XSA-523 advisory, The Hacker News.

  • #xen
  • #xsa-523
  • #virtualization
  • #server-security
  • #ai-security-research
TR

Tommy Rush — Founder, Rush Commerce

Operator turned builder. 15+ years running operations — now shipping the systems businesses run on. More

Get The Rush Report weekly — one email, zero fluff.