MOKSHA-2026-0064: Database Field Poisoning via VDI.xenstore_data Arbitrary Keys

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject arbitrary key-value pairs into VDI.xenstore_data, a field documented as "generally set by the SM backends on vdi_attach." The field has zero map_keys_roles restrictions, zero write-time validation, and zero sanitization. Injected data persists in the XAPI database and is visible to all API consumers. Downstream systems - backup tools, inventory scanners, orchestration platforms - that read VDI.xenstore_data may trust the values as SM-generated storage metadata. The xe CLI reports this field as read-only, but programmatic API access (Python bindings, JSON-RPC, XenOrchestra) bypasses this CLI restriction entirely.

Vulnerability Description

VDI.xenstore_data is a Map(String, String) field defined with ~qualifier:RW at datamodel.ml:6352-6369. The field is designed as a storage metadata channel - SM drivers generate SCSI identity data, storage type identifiers, and VDI UUIDs that flow to guest xenstore during VBD attach.

A critical architectural distinction limits the impact: the XAPI database field and the SM driver's runtime self.xenstore_data Python attribute are completely independent. The SM driver generates xenstore data fresh in memory during every attach operation and does not read the XAPI database field. Injecting data into the database field does NOT inject data into the live xenstore sm-data/ path.

However, the database field is dangerous because:

1. Any key-value pair is accepted without validation
2. The data persists indefinitely in the XAPI database
3. Downstream API consumers have no way to distinguish SM-generated entries from vm-admin-injected entries
4. The data propagates during snapshot, clone, introduce, and pool join operations

The xe CLI restriction (Error: Map field 'xenstore-data' is read-only.) is not a security boundary - it is a CLI-level display decision. The underlying XAPI API exposes full read-write access.

Root Causes

1. Missing RBAC protection. VDI.xenstore_data has zero map_keys_roles entries. Unlike VDI.other_config which has entries for folder and XenCenter.CustomFields.*, this field has no per-key restrictions.

2. No write-time validation. Any key name and any value are accepted. There is no whitelist of valid keys, no format validation, and no content sanitization.

3. SM-internal field exposed to users. The field is documented as "generally set by the SM backends" but has ~qualifier:RW, generating write methods accessible to vm-admin.

4. No provenance tracking. There is no mechanism to distinguish between entries written by SM drivers and entries written by API users.

Affected Systems

Directly Affected

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

Indirectly Affected

• Backup systems - may trust VDI.xenstore_data contents for disk identification and recovery metadata
• Inventory/monitoring tools - aggregate storage metadata from XAPI including xenstore_data
• Orchestration platforms - consume VDI records including potentially poisoned metadata

Exploitation Scenarios

Chaining Analysis

• VXD-1 + VXD-3: Database poisoning (VXD-1) combined with snapshot/clone propagation (VXD-3) fans poisoned metadata through the entire VDI hierarchy.
• VXD-1 + VXD-4: Poisoned data crosses pool boundaries via pool join operations (VXD-4).
• BOC-1 + VXD-1: With root access via BOC-1 S3, the attacker poisons VDI.xenstore_data for all VDIs in the pool by modifying the XAPI database directly.

Detection

• Monitor VDI.xenstore_data for writes by non-SM sessions
• Alert on keys that do not match expected SM-generated patterns (vdi-uuid, scsi/*, storage-type, vdi-type, mem-pool, mem-pool-size)
• Compare VDI xenstore_data against SM driver output for drift detection
• See rule D-01 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VDI.xenstore_data records for unexpected keys
• Restrict vm-admin delegated access to trusted administrators
• Monitor XAPI audit logs for VDI.add_to_xenstore_data calls

Long-Term Fix

Restrict write access. Change write role to _R_POOL_ADMIN or _R_LOCAL_ROOT_ONLY since the field is designed for SM-internal use. There is no legitimate reason for vm-admin to write to this field.

Add key validation. If the field must remain user-writable, validate that keys match expected SM patterns. Reject unknown keys.

Change to DynamicRO. Change the field from ~qualifier:RW to ~qualifier:DynamicRO to eliminate auto-generated write methods entirely.

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

• XAPI source: datamodel.ml:6352-6369 (field definition, ~qualifier:RW, no map_keys_roles), datamodel.ml:6190 (class default _R_VM_ADMIN), xapi_vdi.ml:681 (VDI.create stores user-supplied xenstore_data), xapi_vdi.ml:792 (VDI.introduce stores user-supplied xenstore_data)
• Thematic advisory: disclosure/advisories/vxd-security-advisory.md (VXD-1)
• Investigation: research/investigations/vdi-xenstore-data.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.