XAPI PCI Passthrough RBAC Bypass Vulnerability
[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see: https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root. The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system. Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected. * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0. * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling. * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not. * CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware. * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.
Quick answer
Xen Project XAPI should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- All versions of XAPI according to XSA-489
Fixed versions
- Apply the latest vendor-supported patched version.
How to fix it
XAPI is affected by an RBAC bypass where PCI passthrough configuration was not restricted to pool-admin as expected. Apply the vendor update for XSA-489 and review delegated administrators who could configure host hardware access. This can let a lower-privilege administrator access unintended host hardware through VM configuration.
- Inventory XAPI-based pools and identify environments using RBAC and PCI passthrough.
- Apply the XenServer, XCP-ng, Citrix Hypervisor, or vendor update for XSA-489 covering CVE-2026-23562.
- Restrict PCI passthrough configuration to fully trusted pool administrators until all hosts are patched.
- Review VM PCI passthrough settings, host hardware assignments, and recent XAPI tasks for unauthorized changes.
- Audit vm-admin and delegated administrator activity for changes to host hardware or VM device assignments.
- Rotate administrative credentials and review host integrity if unauthorized passthrough configuration is found.
- Remove unintended PCI device mappings and reboot affected guests or hosts where required by the vendor.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the XAPI pool is updated for XSA-489 and CVE-2026-23562.
- Validate lower-privilege administrators cannot configure PCI passthrough after the fix.
- Review XAPI task history for unexpected host hardware assignment changes.
- Test approved PCI passthrough workflows after patching.
- Run a Fixnx scan and confirm no public virtualization management endpoint is exposed.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-23562?
Xen Project XAPI versions listed as affected should be reviewed: All versions of XAPI according to XSA-489.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
Why can this risk appear in multiple categories?
A vulnerability can belong to more than one platform or ecosystem. Fixnx keeps one canonical risk page while also listing it in every relevant category.