Xen hypervisor flaws let a malicious guest read and write other VMs' memory

What happened

On 4 November 2026, two vulnerabilities in the Xen hypervisor were made public. They allow a malicious guest virtual machine to access the memory of other virtual machines on the same host, including dom0, the privileged control domain. According to the report, an attacker in a guest can both read and write that memory.

Patches are available. There is no mitigation or workaround, so applying the patches is the only protection. Active exploitation has not been reported so far.

Who is affected

All Xen versions since 4.6 are affected. This concerns:

• Administrators and hosting providers who run Xen hosts, either directly or through Xen-based platforms and distributions.
• Anyone who runs VMs for different customers or trust levels on the same Xen host. A single compromised or malicious guest could reach data in every other guest and in dom0.
• Customers of VPS or cloud providers that use Xen. These customers cannot fix the host themselves and depend on their provider to patch.

The risk is highest where untrusted parties control guests, for example in shared hosting or public VPS offerings. Hosts that only run your own trusted VMs are less exposed. They should still be patched, because a compromised guest becomes a path to every other VM on the host.

What to do now

1. List all hosts that run Xen, including those managed through Xen-based virtualization platforms.
2. Check the Xen project security advisories and your distribution's or platform vendor's advisory, linked below, for the patched versions that apply to your release. Fixed version numbers are not included in our source data.
3. Back up the host configuration, such as the Xen and toolstack configuration and the domain configuration files.
4. Migrate or schedule downtime for the guests. A hypervisor update only takes effect after the host has been rebooted.
5. Install the patched Xen packages from your distribution or vendor, or apply the upstream patches and rebuild if you build Xen yourself.
6. Reboot the host into the patched hypervisor, then start the guests again and confirm that they run normally.
7. Patch hosts that run guests from untrusted parties first.
8. If you rent Xen-based VPS, ask your provider whether and when their hosts have been patched.

How to check whether you are affected

• On a Xen host, run xl info in dom0 and look at the xen_major, xen_minor and xen_extra lines. Any version from 4.6 onward is affected unless it includes the patches.
• Compare the installed Xen package version with the fixed version listed in your distribution's or vendor's advisory. On Debian or Ubuntu you can check it with dpkg -l | grep xen, and on RHEL-like systems with rpm -qa | grep xen.
• After you install the update, confirm that the host was actually rebooted into the new hypervisor. Run xl info again and check the uptime.
• Inside a guest, systemd-detect-virt returns xen if you are running on Xen. In that case, the host operator is responsible for patching.

Sources

• https://thehackernews.com/2026/11/xen-hypervisor-flaws-let-one-malicious.html