MOKSHA-2026-0067: Cross-Pool Metadata Injection via VDI.xenstore_data on Pool Join

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can poison VDI.xenstore_data on a source pool, and the poisoned metadata crosses into a target pool when the source host joins the target pool or when VDIs are migrated cross-pool. The pool join code at xapi_pool.ml:1215 copies VDI records including xenstore_data without re-validation. This enables a compromised vm-admin on one pool to inject attacker-controlled storage metadata into a separate, previously uncompromised pool. The field has zero map_keys_roles restrictions, zero write-time validation, and zero cross-pool sanitization.

Vulnerability Description

XAPI pool join operations merge the database of the joining host into the pool master's database. VDI records are copied as part of this process.

The code path at xapi_pool.ml:1215:

~xenstore_data:vdi.API.vDI_xenstore_data

This line copies the joining host's VDI.xenstore_data directly into the target pool's VDI record. No validation, no sanitization, no re-generation from the SM driver.

The attack sequence:

1. vm-admin poisons VDI.xenstore_data on source pool VDI with attacker-controlled values
2. Source host initiates pool join to target pool
3. xapi_pool.ml:1215 copies VDI records including poisoned xenstore_data to target
4. Target pool now contains VDI records with attacker-controlled metadata
5. Downstream consumers on the target pool trust the inherited metadata

Cross-pool migration (SXM - Storage XenMotion) follows a similar pattern: VDI records are recreated on the target pool using metadata from the source, including xenstore_data.

This vector requires pool join or cross-pool migration as a trigger event, making it less immediately exploitable than direct database writes. However, pool joins are a routine operational event in infrastructure lifecycle management (capacity expansion, host replacement, pool consolidation).

Root Causes

1. No cross-pool sanitization. Pool join copies VDI metadata across pool trust boundaries without any validation or re-generation.

2. Implicit trust of source pool data. The target pool assumes all metadata from the joining host is legitimate. There is no integrity verification.

3. Missing RBAC protection. The source pool's vm-admin can poison metadata that will be trusted by the target pool.

4. No write-time validation. The initial poisoning is possible because the field accepts any key-value pair without validation.

Affected Systems

Directly Affected

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

Indirectly Affected

• Target pool infrastructure - inherits poisoned metadata from joining host
• Cross-pool migration consumers - VDI records on target pool contain attacker-controlled data
• Backup and DR systems - replicated metadata may include poisoned entries

Exploitation Scenarios

Chaining Analysis

• VXD-4 + VXD-1: Database poisoning (VXD-1) on the source pool, followed by cross-pool propagation (VXD-4) to the target.
• VXD-4 + VXD-2: Forged SCSI identities (VXD-2) on the source pool cross into the target pool, causing disk misidentification across pool boundaries.
• VXD-4 + VXD-3: Poisoned VDIs on the source pool are snapshotted on the target pool, amplifying the contamination through the target's snapshot hierarchy.

Detection

• Audit VDI xenstore_data after pool join operations for unexpected entries
• Compare VDI metadata against SM driver output on the target pool after join
• Monitor pool join events and flag VDIs with non-standard xenstore_data keys
• See rule D-04 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit VDI records after pool join for unexpected xenstore_data entries
• Re-validate VDI metadata against SM drivers after pool join
• Restrict pool join operations to trusted sources

Long-Term Fix

Re-generate xenstore_data on pool join. Instead of copying the source pool's database field, query the SM driver on the target pool for fresh metadata after the VDI's storage is available.

Add cross-pool validation. Validate xenstore_data entries against a whitelist of SM-known keys during pool join. Reject or strip unknown keys.

Restrict write access. Change the field write role to _R_POOL_ADMIN to prevent vm-admin from poisoning the source data in the first place.

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: xapi_pool.ml:1215 (pool join copies xenstore_data across pool boundary), datamodel.ml:6352-6369 (field definition, no map_keys_roles), xapi_vdi.ml:792 (VDI.introduce/db_introduce stores xenstore_data)
• Thematic advisory: disclosure/advisories/vxd-security-advisory.md (VXD-4)
• Investigation: research/investigations/vdi-xenstore-data.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.