criticalCVE-2026-23561

XAPI Storage Driver Domain 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.

ProductXAPI
CVSS9.4
EPSSNot scored yet
UpdatedJuly 9, 2026

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 involving VM.other_config:storage_driver_domain, allowing a vm-admin to mark a VM as a storage domain. Apply the XSA-489 vendor update and inspect storage driver domain settings. The risk is disruption or manipulation of host storage state by delegated administrators who should not control storage domains.

  1. Inventory XAPI-based pools, storage repositories, PBDs, and delegated RBAC roles.
  2. Apply the vendor XAPI update for XSA-489 covering CVE-2026-23561.
  3. Temporarily limit vm-admin permissions for storage-related operations until patching is complete.
  4. Review VM.other_config:storage_driver_domain values and recent storage domain changes.
  5. Inspect PBD state changes, storage detach events, and XAPI task logs for suspicious activity.
  6. Rotate administrator credentials and review storage repository integrity if unauthorized changes are discovered.
  7. Restore known-good storage configuration and validate all SRs and PBDs after remediation.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm all pool hosts are updated for XSA-489 and CVE-2026-23561.
  • Validate vm-admin users cannot mark VMs as storage driver domains without proper authority.
  • Review XAPI logs for suspicious storage domain and PBD state changes.
  • Test normal storage attach, detach, migration, and VM lifecycle operations after the fix.
  • Run a Fixnx scan and confirm no public virtualization management endpoint is exposed.

Related categories

Trusted references

FAQ

What is affected by CVE-2026-23561?

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.