XSA-468: multiple Windows PV driver vulnerabilities - update now!

dinhngtu

XSA-468: multiple Windows PV driver vulnerabilities - update now!

Original announcement: https://xcp-ng.org/blog/2025/05/27/xsa-468-windows-pv-driver-vulnerabilities/.
Check the XCP-ng docs for the latest updates.

Summary

Multiple vulnerabilities have been discovered in all existing Xen PV drivers for Windows from all vendors (XCP-ng, XenServer, etc.) published prior to the disclosure, on May 2025.

These vulnerabilities allow unprivileged users to gain system privileges inside Windows guests.

These issues have the following identifiers:

CVE-2025-27462
CVE-2025-27463
CVE-2025-27464

Am I affected?

Windows guests running vulnerable versions of Xen PV drivers are affected. Other guest OSes are not affected.

To check if you're affected, verify the version of Xen PV drivers in Device Manager.

Driver version numbers are independent from Xen PV tools package versions. Use the methods below to check the precise driver versions.

XCP-ng PV Bus, XCP-ng Interface and XCP-ng PV Console older than 9.0.9065 are affected.
XenServer/Citrix PV Bus older than 9.1.11.115; PV Interface older than 9.1.12.94 are affected.
Other Xen PV drivers for Windows are also likely affected. If you are using these drivers, verify each vendor's security bulletins for more details.

You can check for this vulnerability from within the Windows VMs themselves (most precise, recommended) but also from outside the VMs, using tools we built for this purpose.

If you are reading this article shortly after its publication, it's likely that all of your Windows VMs are vulnerable.
Once patched, follow these instructions to verify that your VMs are no longer vulnerable.

Check a Windows VM for vulnerability

This is the most precise way, but needs to be done per VM.

Verify the version numbers in Device Manager.
Use the mitigation script published in the XSA-468 advisory in -Scan mode (will only report the vulnerability, not version numbers). See the script for documentation.

Detect vulnerable VMs at the pool level

This method requires the latest XCP-ng updates to be applied, in XCP-ng 8.2 and 8.3.

We developed two features to help you with the handling of these vulnerabilities.

A host-side detection script, that you can run in dom0. It will list affected Windows VMs based on their PV driver versions. See the script for documentation.
A warning ️ sign next to affected VMs and a vulnerable? filter in Xen Orchestra. These features will be made available very soon, through an update to the stable channel. Keep an eye on the XCP-ng documentation for announcements.

This detection depends on XAPI accurately reporting PV driver versions. Prior to the recent XCP-ng 8.2 and 8.3 updates released in May 2025, this was not the case. As a result, the detection tools cannot assess VMs that have not been run since the updates were applied. If no driver information is available, a warning will be displayed.

️ Only virtual machines (VMs) created using a Windows template—or from templates or VMs originally derived from one—can be detected by these tools. They are designed to help users identify vulnerable VMs that may have been overlooked, forgotten during patching, or restored from backups taken before vulnerability fixes were applied. These tools are not intended to serve as comprehensive detection solutions, so do not rely on them exclusively.

How to patch my VMs?

First, create backups and snapshot your VMs before updating.

If you're using XenServer Windows PV drivers or have enabled the "Manage Citrix PV drivers via Windows Update" feature: Upgrade to XenServer VM Tools 9.4.1 or later.

If you're using XCP-ng Windows PV drivers 8.2.x, you should use XenClean to remove the existing drivers, then choose one of the following:

On a production system, install XenServer VM Tools 9.4.1 or later;
If you're not running a production system, and want to test the latest XCP-ng Windows PV drivers: install XCP-ng driver version 9.0.9065 or later. (Note that this requires bringing Windows into test signing mode)

If you're already using XCP-ng Windows PV drivers 9.0: Install XCP-ng driver version 9.0.9065 or later.

I can't patch now, what should I do?

You are encouraged to apply the latest updates as soon as possible.

If you absolutely cannot update, apply the mitigation script provided by Vates and the Xen Project, available at https://xenbits.xen.org/xsa/advisory-468.html.

Note that this mitigation script only covers vulnerabilities in the Xen PV Interface driver.

You should run the mitigation script in Scan mode afterwards to make sure the vulnerability is effectively mitigated.

How is Vates helping to address this vulnerability?

This issue was discovered by Vates as part of our investment into upstream Xen development. Vates VMS provides multiple facilities to help users affected this issue:

We developed fixes for these vulnerabilities, which have been integrated upstream.
We provided a mitigation script for those who cannot install the update.
We have added detection logic in Xen Orchestra's latest release channel to actively alert on vulnerable Windows VMs. We also updated XCP-ng 8.2 and 8.3 so that PV driver versions are reported to Xen Orchestra for it to detect vulnerable Windows VMs. See "Am I affected?" above.
We have developed a script that can be run in dom0 to perform the same detection, in case Xen Orchestra’s detection logic is not yet available to you. See "Am I affected?" above.
We are publishing an alert about the vulnerability inside all Xen Orchestra appliances.
We alert about this vulnerability at the beginning of our latest newsletter.

Why can't I use XCP-ng Windows PV drivers in production?

The XCP-ng 9.0 drivers aren't signed by Microsoft yet, and thus currently require putting Windows into test mode. As a result, these drivers are not appropriate for production use.

You may have noticed that the XCP-ng 8.2 Windows drivers can still be used when Secure Boot is disabled. This is due to these drivers being signed before Microsoft changed the driver signing rules and forcing 1st-party driver signatures.

We are actively working with Microsoft to get the drivers signed (which is a slow process). An announcement will be made as soon as a Microsoft-signed build is available.

Related links

Xen Project announcement: https://xenbits.xen.org/xsa/advisory-468.html
XenServer Security Bulletin: https://support.citrix.com/article/CTX692748

Forza

Hi,

It is not clear to me if the old XCP-ng PV drivers (8.2.2.200-RC1) are affected or not. How should we proceed if they are? AFAIK it is no easy task to migrate to WindowsUpdate drivers and it usually ends up with some issue.

dinhngtu

@Forza Yes, all XCP-ng drivers before 9.0.9065 are affected, including 8.2.x.

There's no need to enable the "Manage Citrix PV drivers via Windows Update" option. You should remove the existing drivers with XenClean and install XenServer drivers 9.4.1 or later. (See the "How to patch my VMs?" section for detailed instructions)

If updating is absolutely not an option, you can try the mitigation script, but be aware that it's only a bandaid and not meant to be a long-term or complete fix.

flakpyro

Until the XO update is released by Vates you can filter your PV Driver version using the following:

pvDriversVersion:!9.4.1

This will show you all VMs not running that version. If you have Linux VMs they will be shown in this filter. If you have tagged your windows VMs you can combine this with a tag for example:

power_state:running pvDriversVersion:!9.4.1 tags:/^Windows$/

Remove the ! to filter for VMs that are running the latest 9.4.1 version.

dinhngtu

Hi all,

Xen Orchestra 5.107.0 (latest channel) and 5.106.4 (stable channel) have been released. They contain the automatic alert and vulnerable? filter for Windows VMs affected by XSA-468.

conitrade-as

After upgrading the VM tools the mitigation script still shows vulnerable devices on some hosts. After running the script to apply the mitigations, nothing is reported as being vulnerable anymore.

Thus the question: Is applying the mitigations a necessary action as well? Or does installing the v9.4.1 tools fix the vulnerability?

dinhngtu

@conitrade-as Installing the XenServer 9.4.1 tools and rebooting (a couple times) will be enough. Do your VMs show as vulnerable (red) or unable to detect (orange)? There are some new host XAPI updates for correcting driver version reporting that are needed for the XO feature to work.

conitrade-as

@dinhngtu Ok, I will keep that in mind as I go through all the VMs. As I currently cannot update XCP-ng on all hosts (8.2.1 LTS), the VMs where the new tools were installed and mitigations applied show up as "orange".

On a XCP-ng 8.3 test hosts with all updates applied the detection works as advertised.

DustinB

@dinhngtu said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@conitrade-as Installing the XenServer 9.4.1 tools and rebooting (a couple times) will be enough.

The multiple reboots is the annoying part, ha... working on my systems now. I've always used https://www.xenserver.com/downloads for this.

On numerous VM's I've been installing over top of the existing drivers and within System Manager I still see

.

Should I just uninstall the old stuff first, then install the updated to address?

dinhngtu

@conitrade-as The XAPI update was backported to 8.2.1 LTS so you could update your hosts for the new display.

@DustinB If you're coming from old XenServer tools to new, no need to uninstall.

DustinB

@dinhngtu said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@DustinB If you're coming from old XenServer tools to new, no need to uninstall.

Interesting, the alert is still within XOA

...

dinhngtu

@DustinB Do you have the newest pool updates? The warning depends on that.

DustinB

@dinhngtu said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@DustinB Do you have the newest pool updates? The warning depends on that.

I have an open ticket for that.....

conitrade-as

@dinhngtu On a Windows 10 VM rebooting alone did not do the trick. After 5 reboots the script still reports vulnerable devices:

.\Install-XSA468Workaround.ps1 -Scan

Looking for vulnerable XenIface objects
Found vulnerable object XENBUS\VEN_XSC000&DEV_IFACE\_
Found vulnerable object XENBUS\VEN_XSC000&DEV_IFACE\_

Looking for vulnerable XenIface WMI GUIDs
Found vulnerable WMI GUID 1D80EB99-A1D6-4492-B62F-8B4549FF0B5E
Found vulnerable WMI GUID 12138A69-97B2-49DD-B9DE-54749AABC789
Found vulnerable WMI GUID AB8136BF-8EA7-420D-ADAD-89C83E587925

Found XenIface vulnerability, it's recommended to run the script
True

Running .\Install-XSA468Workaround.ps1 works as expected. After another reboot nothing is reported as being vulnerable anymore.

On a Windows 2019 Server I saw the behaviour you described: Installing the tools and a reboot was enough.

conitrade-as

On another Windows 10 host it worked. What was different: I saw the message box "Tools have been installed successfully". May be that makes a difference?

dinhngtu

@conitrade-as I saw that on your Windows 10 VM, the "Manage Citrix PV drivers via Windows Update" option is enabled. That one might have needed a Windows Update to install the fixed drivers. Do you have that option enabled in other VMs?

conitrade-as

@dinhngtu On the machine where it worked, the option "Manage Citrix PV drivers via Windows Update" was not enabled. Seems that my older BIOS Windows 10 VMs have that option enabled. On all UEFI VMs the options is disabled.

As I wanted to go and check that is present in the templates, I realized that the Windows Templates are gone from Xen Orchestra v5.106.4???

DustinB

@conitrade-as said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

As I wanted to go and check that is present in the templates, I realized that the Windows Templates are gone from Xen Orchestra v5.106.4??

Can confirm all templates for Windows are missing on 5.107.0 as well.

dinhngtu

@conitrade-as @DustinB Thanks, reported the template issue to XO team.

conitrade-as

Here is another interesting fact: After installing the new tools (v.9.4.1) my static routes in Windows were all gone. Definitively a good way to loose connectivity to your domain controller. And that's why you have good monitoring and store things in Ansible et al. ...