← Back to articles
Security· 3 min read

Xen XSA-478 (CVE-2025-58151): a TOCTOU flaw in varstored enables privilege escalation from the VM

On 27 January 2026 the Xen Project published security advisory XSA-478, which fixes CVE-2025-58151 in varstored. This is a TOCTOU (Time-of-Check-Time-of-Use) race condition that can allow an attacker with kernel-level access inside a virtual machine to escalate privileges and execute code outside it.

What varstored is and where the problem lies

varstored is a component of the Xapi toolstack (the management stack used by Xen-based platforms such as XenServer/XCP-ng) responsible for managing the UEFI variables of virtual machines. To do this, varstored accesses a shared memory buffer with the guest.

The flaw stems from insufficient compiler barriers when accessing that shared buffer. Because the guest can modify the contents of memory between the moment varstored checks it and the moment it uses it (hence the TOCTOU name), race conditions are introduced. According to the advisory, depending on the code the compiler generates, an attacker may be able to control jump table indices, which opens the door to arbitrary code execution within varstored.

Who is affected

The vulnerability affects only deployments using the Xapi toolstack, and according to the official advisory, all versions of varstored are vulnerable.

For the issue to be exploitable, these conditions must be met:

  • The guest must be an x86 HVM virtual machine configured as a UEFI VM (that is, with firmware=uefi in the HVM boot parameters).
  • PV guests and VMs configured with traditional BIOS are not exploitable.

It is important to stress that the attacker needs kernel-level access inside the VM to leverage the flaw. This is not an attack launched directly from outside the host: the scenario is one where an attacker already controls a UEFI guest and wants to break out toward the host toolstack.

Severity and impact

The advisory classifies the impact as privilege escalation: an attacker controlling the VM kernel can execute code within varstored, which runs in the host context. This breaks the isolation expected between the virtual machine and the management infrastructure, which is especially serious in multi-tenant environments (multiple customers sharing hardware). In our incident list we have rated it high severity.

Mitigation and patch

According to the Xen advisory, there are no workarounds: the only way to mitigate the vulnerability is to apply the patch released by the project (xsa478.patch). If you operate a Xapi-based platform (XenServer, XCP-ng or derivatives), the practical recommendations are:

  • Update varstored as soon as your distribution or vendor publishes the fixed packages.
  • In the meantime, review which VMs use UEFI and assess the trust level of whoever operates them, since the vector requires control of the guest kernel.
  • Keep up with the rest of the Xen advisories from the same batch (XSA-477 and XSA-479 were published on the same date), which are best applied together.

This incident is a good reminder that virtualization security does not end at the hypervisor: the toolstack and auxiliary components such as varstored are also part of the attack surface, and a shared-memory synchronization flaw can be just as serious as a flaw in Xen itself.

Source