MOKSHA-2026-0083: Boot Order Manipulation via VM.HVM_boot_params order

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can set an arbitrary boot order string in VM.HVM_boot_params:order. The value is passed verbatim to QEMU as the -boot order=<value> argument via device.ml:3957-3958. XAPI performs no validation on the boot order string beyond replacing empty values with the default "cd" at xapi_xenops.ml:469-475. QEMU silently ignores unrecognized characters, limiting the practical impact to forcing PXE network boot (order=n) when the attacker also controls DHCP/PXE infrastructure. The VM.HVM_boot_params field has zero map_keys_roles entries.

Vulnerability Description

VM.HVM_boot_params is a Map(String, String) field defined at datamodel_vm.ml:55-58 with zero map_keys_roles entries and _R_VM_ADMIN as the default write role.

The order key flows from XAPI to QEMU:

1. vm-admin writes HVM_boot_params:order=n via VM.add_to_HVM_boot_params
2. XAPI reads the value at xapi_xenops.ml:469-475 via assume_default_if_null_empty
3. If the value is empty or missing, it defaults to "cd"; otherwise the raw value passes through
4. The value is included in the hvm_info.boot_order record sent to xenopsd
5. xenopsd constructs QEMU argument: "-boot"; "order=" ^ info.Dm_Common.boot at device.ml:3957-3958
6. QEMU is invoked via execve (no shell injection possible)
7. QEMU interprets recognized characters (a=floppy, b=floppy, c=hard disk, d=CD-ROM, n=network PXE)
8. Unrecognized characters are silently ignored

The use of execve via Forkhelpers.safe_close_and_exec prevents shell metacharacter injection. The practical attack surface is limited to selecting boot devices from the set that QEMU recognizes.

Root Causes

1. Missing RBAC protection. VM.HVM_boot_params has zero map_keys_roles entries in datamodel_vm.ml. The order key is writable by vm-admin.

2. Missing write-time validation. The boot order string is not validated against the set of recognized QEMU boot device characters (a, b, c, d, n). Any string is accepted.

3. set_HVM_boot_params RBAC bypass. The set_HVM_boot_params method replaces the entire map and bypasses map_keys_roles per-key checks.

Affected Systems

Directly Affected

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

Indirectly Affected

• Guest VMs - boot order manipulation affects which device the VM boots from
• PXE-dependent environments - VMs forced to PXE boot load images from network infrastructure

Exploitation Scenarios

Chaining Analysis

• BOC-1 + HBP-1: BOC-1 does not lower the RBAC barrier (already vm-admin). With root access, an attacker could modify DHCP/PXE configuration on the host to serve malicious boot images, but BOC-1 alone provides more direct attack paths.
• SMC-1: No interaction. Boot parameters do not touch storage protocol traffic.
• hvm_serial (#191): No interaction. Boot order cannot create files on the host filesystem.
• The vm-admin already controls VIF assignments and network configuration, reducing the incremental value of boot order manipulation.

Detection

• Monitor VM.HVM_boot_params for unexpected order values containing n (PXE boot)
• Alert on boot order changes outside maintenance windows
• See rule H-01 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VM.HVM_boot_params entries for unexpected order values
• Monitor for VMs with PXE boot enabled that should not have it
• Restrict XAPI API access to trusted networks

Long-Term Fix

Add boot order validation. Restrict the order value to characters from the set {a, b, c, d, n} and enforce a maximum length at write time or at XAPI-to-xenopsd translation time.

Add map_keys_roles protection. Restrict the order key to _R_POOL_ADMIN in datamodel_vm.ml.

Replace with typed fields. The order key has a small, well-defined value set. It should be an enumeration field, not a free-form string in a map.

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-0084 (HBP-2)
• XAPI source: datamodel_vm.ml:55-58 (VM.HVM_boot_params field definition), xapi_xenops.ml:469-475 (boot order read + default), xapi_xenops.ml:213-219 (assume_default_if_null_empty), device.ml:3957-3958 (QEMU -boot argument)
• Thematic advisory: disclosure/advisories/hbp-security-advisory.md (HBP-1)
• Investigation: research/investigations/vm-hvm-boot-params.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.