MOKSHA-2026-0009: QEMU Serial Host Filesystem Write via VM.platform hvm_serial

Summary

A user with the vm-admin role can write arbitrary host filesystem files by setting VM.platform:hvm_serial to file:<path>. XAPI reads this key from the raw database record (bypassing the filtered_flags allowlist) and passes it to QEMU as the -serial argument. QEMU creates the target file on the host filesystem even if the VM fails to fully start. This is an independent host filesystem write primitive that chains into all 34 FIST debug points in XAPI without requiring BOC-1. The file is created with root ownership because QEMU runs as root in dom0.

Vulnerability Description

VM.platform is a Map(String, String) field controlling hypervisor-level VM configuration. The hvm_serial key specifies the QEMU serial device. XAPI reads this key at xapi_xenops.ml:456 from the raw vm.API.vM_platform database value - not from the filtered platformdata that passes through sanity_check.

The filtered_flags Bypass

XAPI applies a filtered_flags allowlist to VM.platform before passing values to xenopsd. This allowlist blocks unrecognized keys from reaching the QEMU command line. However, hvm_serial is read independently from the raw database record at line 456, completely bypassing the allowlist:

1. hvm_serial is NOT in filtered_flags
2. filtered_flags prevents it from reaching platformdata
3. BUT xapi_xenops.ml:456 reads it from raw vm.API.vM_platform
4. The value is passed directly to xenopsd as the serial field in HVM info
5. xenopsd passes it verbatim to QEMU: -serial file:<path>

File Creation Without VM Boot

QEMU creates the file specified in the -serial file:<path> argument during its own initialization, before the VM domain is fully created. If domain creation fails for any reason, the file still exists. This means:

• No successful VM boot is required
• The file is created with root:root ownership
• The file persists regardless of the VM's eventual state
• The attacker needs only VM.add_to_platform + VM.start (which can fail)

Live Verification

[root@xcpng ~]# /usr/lib64/xen/bin/qemu-system-i386 -accel xen \
    -serial "file:/tmp/test-serial-qemu-check" -M none
[root@xcpng ~]# ls -la /tmp/test-serial-qemu-check
-rw-r--r-- 1 root root 0 Feb  7 14:01 /tmp/test-serial-qemu-check

Confirmed on the live production host: QEMU creates the file as root.

Root Causes

1. filtered_flags bypass. hvm_serial is read from the raw database record, not from the filtered platformdata. The allowlist provides zero protection for this key.

2. Missing per-key RBAC. VM.platform has zero map_keys_roles entries. All keys are writable by vm-admin.

3. No write-time validation. All VM.platform validation occurs at VM start time (sanity_check), not at write time. The malicious value persists in the database.

4. QEMU file creation at init. QEMU creates the serial output file during its own initialization before checking whether the VM domain is viable. This guarantees file creation regardless of VM start success.

Affected Systems

Directly Affected

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

Indirectly Affected

• Host stability - FIST point file creation disables internal checks (HA, memory validation, storage operations)
• Pool-wide impact - some FIST points affect pool-level operations
• All VMs on the host - FIST points that disable HA or memory checks affect the entire host

Exploitation Scenarios

FIST Debug Points (Partial List)

There are 34 FIST points in XAPI, each controllable via this primitive.

Detection

• Monitor QEMU process arguments for -serial file: with paths outside /dev/
• Audit /tmp/fist_* files on all hosts - these should not exist in production
• Alert on VM.platform:hvm_serial set to any value containing file:
• See rule X-06 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VM.platform entries for hvm_serial containing file: prefix
• Remove any unexpected /tmp/fist_* files from all hosts
• Monitor QEMU command-line arguments at VM start

Long-Term Fix

Validate hvm_serial. Restrict the hvm_serial value to known safe serial device types. Reject file: prefix entirely - there is no legitimate use case for QEMU serial output to host filesystem in production.

Add map_keys_roles. Add per-key RBAC for hvm_serial requiring _R_POOL_ADMIN in datamodel.ml.

Fix the filtered_flags bypass. Read hvm_serial from filtered platformdata, not from the raw database value. This ensures the allowlist is applied consistently.

Add write-time validation. Validate platform key values when they are set, not just at VM start.

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-0001 (BOC-1 - alternative host filesystem write primitive)
• XAPI source: xapi_xenops.ml:456 (hvm_serial read from raw platform), vm_platform.ml (sanity_check / filtered_flags), xenops_server_xen.ml (QEMU command line construction)
• Thematic advisory: disclosure/advisories/plat-security-advisory.md (PLAT-6)
• Investigation: research/investigations/vm-platform.md
• Evidence: Live test on 10.20.30.102 confirmed file creation via QEMU -serial file: argument

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.