MOKSHA-2026-0001: Arbitrary Host Device Mount via VBD.other_config backend-local

Summary

A user with the vm-admin role - the lowest delegated management role in XAPI-based hypervisors (XenServer, XCP-ng) - can mount any host block device as a guest virtual disk by writing an arbitrary filesystem path to VBD.other_config:backend-local. The attack requires a single API call, no exploit code, no shell access, and produces no security alerts. The vulnerability collapses the entire XAPI RBAC hierarchy: a vm-admin gains root-equivalent access to the hypervisor host, can read any co-hosted VM's disk, exfiltrate credentials, inject SSH backdoors, and move laterally across shared storage - all from a single delegated admin credential.

Vulnerability Description

VBD.other_config is a Map(String, String) field in the XAPI data model. The backend-local key overrides the normal storage path for a virtual block device. When a VBD is plugged (via VM start or hotplug), XAPI reads this key in xapi_xenops.ml:backend_of_vbd and passes the path directly to xenopsd with no validation, no access control check, and only a warn-level log message.

The code path:

1. vm-admin calls VBD.add_to_other_config(vbd, "backend-local", "/dev/sda1")
2. On VBD plug, xapi_xenops.ml:backend_of_vbd reads other_config["backend-local"]
3. The path is forwarded to xenopsd as the VBD backend device
4. xenopsd writes the path to xenstore; blkback opens it in dom0
5. The guest VM sees the host block device as a virtual disk

No validation occurs at any stage. The warn-level log message ("Using local override for VBD backend") is the only trace of the operation.

Root Causes

1. Missing RBAC protection. VBD.other_config has zero map_keys_roles entries in datamodel.ml. Every infrastructure-critical key, including backend-local, is writable by vm-admin via add_to_other_config.

2. Missing consumer-side validation. backend_of_vbd in xapi_xenops.ml consumes the backend-local key without any path validation, access control check, or security-level logging.

3. set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks entirely. This is a pre-existing architectural limitation shared by all XAPI objects.

4. Insufficient logging. The only indicator is a warn-level message. No security alert, no RBAC denial event, no anomaly detection trigger.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (tested on 8.3.0)
• Any XAPI-based hypervisor distribution

Indirectly Affected

• Storage arrays connected to affected pools (iSCSI, NFS, FC, SMB) - via BOC-1 + SMC-1 chain, the compromised host becomes a silent storage attack proxy
• Management orchestrators (Xen Orchestra, CloudStack, OpenStack) - trust assumptions about XAPI data integrity are invalidated
• Backup systems - trust XAPI metadata that an attacker can now modify
• Monitoring systems - consume XAPI data without independent validation
• Every VM in the pool - co-hosted VMs have their virtual disks exposed via shared or local storage

Exploitation Scenarios

Confirmed (Live-Tested)

Additional Scenarios

Escalation Chain

vm-admin credential (single API call)
    |
    v
S1: Read any VM's VDI on the same host
    |
    +---> S7: Read VDIs from remote host's local storage
    |
    v
S2: Read the host root filesystem
    |
    +---> S3: Self-grant pool-admin (permanent RBAC collapse)
    +---> S4: SSH key injection (persistent root access)
    +---> S5: Shared storage lateral movement (pool-wide compromise)
    +---> S6: pool-admin + SMC-1 (silent storage array attacks)
    +---> S8: USB device exfiltration

Detection

• Monitor XAPI logs for the message "Using local override for VBD backend" - this is the only indicator
• Audit all VBD.other_config entries for the backend-local key: any non-empty value is suspicious
• See rule X-01 in disclosure/vendor-detection-guidance.md

There is no reliable post-compromise detection. The S3 RBAC collapse leaves no API audit trail because the role change is loaded from the tampered on-disk database at XAPI startup, not modified through the API. XAPI performs no integrity verification on state.db at load time.

Remediation

Short-Term Mitigations

• Revoke all vm-admin delegated access immediately
• Audit all VBD.other_config records for unexpected backend-local keys
• Monitor XAPI logs for "Using local override for VBD backend" messages
• Restrict XAPI API access to trusted networks

Long-Term Fix

Layer 1 - RBAC (Patch 0001): Add map_keys_roles entries to VBD.other_config in datamodel.ml. The backend-local key requires _R_LOCAL_ROOT_ONLY (no API user can set it). The backend-kind key requires _R_POOL_ADMIN.

Layer 2 - Validation (Patch 0002): Add a config-driven validation gate in xapi_xenops.ml:backend_of_vbd. A new flag allow_vbd_backend_local (default: false) rejects the override when disabled. Defense-in-depth: blocks the attack even if RBAC is bypassed via set_other_config.

Upstream patches exist. They are held privately pending coordinated disclosure.

Disclosure

Disclosure:

• Public release: 2026-04-24 08:00 CEST
• CERT/CC notified: 2026-04-23
• MITRE CVE reservation filed: 2026-04-09 (no response as of publication)
• EU CVE registers notified: 2026-04-18 (GCVE/CIRCL, ENISA, DIVD - no response)
• Vendor (Cloud Software Group / Citrix): not contacted pre-publication
• Downstream maintainer (Vates/XCP-ng): contacted 2026-04-23 with conditional patch offer

References

• Related MOKSHA IDs: MOKSHA-2026-0007 (BOC-2 backend-kind type confusion)
• XAPI source: xapi_xenops.ml:backend_of_vbd, datamodel.ml (VBD field definition)
• Thematic advisory: disclosure/advisories/boc-1-security-advisory.md
• Investigation: research/investigations/vbd-other-config.md
• PoC scripts: research/boc-1/poc/ (available to CSIRTs on request)

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.