The Xen Project has patched two critical flaws in its hypervisor that could let a single malicious virtual machine read and write the memory of every other virtual machine on the same host, including the privileged management domain that controls the whole system. The flaws, disclosed on November 3 in advisory XSA-523, affect every Xen release from version 4.6 onward, and there is no workaround. The Xen Project credits Anthropic with finding them using Claude, and states that credit in the advisory itself.
What the flaws do
The flaws sit in grant copy, the operation Xen uses to copy data between virtual machines. Each machine tells Xen which of its memory pages others may use, and Xen checks those permissions. To save time on a batch of copies within the same memory page, Xen reuses checks it has already made.
It did not check again when it should have, and that mistake is what lets a malicious guest read and write memory it does not own. The two flaws are tracked as CVE-2026-102703, where frame numbers and grant references could be mixed up, and CVE-2026-102704, where a check on copying by frame number was enforced in the wrong place.
Who is affected, and what the fix looks like
Every Xen version from 4.6 onward is vulnerable, while 4.5 and earlier are not. Patches cover Xen 4.17 through 4.19 and the unstable branch, and platforms built on Xen have issued their own updates: XCP-ng shipped a fix for its 8.3 release on November 3, and Qubes OS fixed its 4.3 release, the only version it still supports.
Versions 4.6 through 4.16 have no patch in the advisory, because support for 4.16 ended in December 2024, so operators on those releases must upgrade. The advisory reports no known exploitation of either flaw, and neither CVE appears in the US CISA Known Exploited Vulnerabilities catalog as of November 4.
How Claude found them
The disclosure is notable for who found the flaws. The Xen Project formally credits Anthropic, using its Claude model, with the discovery, and Stephan Lipp of Ada Logics validated the findings. The CodeAnt AI Security Research Team reported the same issues independently.
The patch commits carry a trailing line reading 'Assisted-by: Claude.' CodeAnt later published a working guest-to-dom0 escape, which it calls Xenbleed, running code in the dom0 kernel from a guest VM, and put its own severity assessment at 9.3 under CVSS 3.1 and 9.4 under CVSS 4.0.
Our Read
This is the clearest evidence yet that AI models are becoming working security researchers, not just assistants that write code. Claude did not merely flag a suspicious pattern; its finding survived independent validation, produced patches for a hypervisor that underpins real clouds, and earned formal credit in the advisory itself.
The parallel with OpenAI's GPT-6 Cyber, which found dozens of browser and kernel flaws the same week, is hard to miss: the labs are now racing to show their models finding bugs before anyone else's do. The uncomfortable side is the same capability in the wrong hands, which is why the credit line matters as much as the patch.
Why It Matters
For cloud operators, the flaws are urgent: a malicious guest escaping to dom0 can take over the whole host, and there is no workaround short of patching and rebooting. For the AI industry, the credit line is the story: a model that finds critical flaws in infrastructure code has a measurable, public track record.
For everyone else, it is a reminder that the software running the cloud still hides bugs a decade old — this one traces to a performance change from 2015 — and that the next one may be found by a model before a human ever looks.
Background
Xen is one of the hypervisors underpinning cloud computing, and grant copy is how its virtual machines share memory through the hypervisor. This is not the first grant-copy flaw: XSA-500, disclosed on July 28, covered a related weakness. The difference this time is the finder — an AI model credited by name — and the proof that the escape works.
Source: Xen Project advisory XSA-523 and The Hacker News report
0 Comments