MOKSHA-2026-0057: FIST Namespace Exposure via VM.xenstore_data

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject FIST/-prefixed keys into VM.xenstore_data, polluting the Fault Injection Service Testing (FIST) namespace. The FIST prefix is included in allowed_xsdata_prefixes at domain.ml:164, allowing keys starting with FIST/ to pass through the xenopsd filter and be written to guest xenstore. While XAPI's actual fault injection mechanism reads /tmp/fist_* files on disk (not xenstore entries), the namespace pollution persists in the XAPI database across VM restarts, is visible to all API consumers, and establishes a pre-positioned injection path if any future code adds xenstore-based FIST consumption. The field has zero map_keys_roles entries.

Vulnerability Description

VM.xenstore_data is a Map(String, String) field writable by vm-admin with zero per-key RBAC. The only security control is a prefix filter in xenopsd at domain.ml:164-170 that accepts keys starting with vm-data/ or FIST/.

The code path:

1. vm-admin writes a FIST-prefixed key: VM.add_to_xenstore_data(vm, "FIST/disable_reboot", "1")
2. XAPI stores the value in the database immediately with zero validation (message_forwarding.ml:2092-2099)
3. The key passes the filtered_xsdata prefix check at domain.ml:164-170 because FIST is in allowed_xsdata_prefixes
4. The key is written to guest xenstore at /local/domain/<domid>/FIST/disable_reboot
5. On VM restart, the FIST key is rewritten to the new domain's xenstore from the database

The FIST namespace in xenstore is not connected to XAPI's actual fault injection mechanism (xapi_fist.ml), which checks for /tmp/fist_* files on disk. The two mechanisms share a namespace but are not linked. The xenstore path is a data passthrough only.

The security concerns:

• The FIST/ prefix serves no legitimate user purpose - it was added for internal developer testing
• vm-admin and guests can inject FIST-prefixed data that persists across VM restarts
• FIST keys in VM.xenstore_data are visible to all XAPI API consumers (XenCenter, XO, scripts)
• If any future code adds xenstore-based FIST consumption, the injection path is already established

Root Causes

1. Debug namespace exposed to unprivileged users. The FIST/ prefix is included in allowed_xsdata_prefixes alongside vm-data/, granting vm-admin write access to a debugging namespace.

2. Missing RBAC protection. VM.xenstore_data has zero map_keys_roles entries. No key prefix is restricted to a higher privilege level.

3. Persistent data injection. FIST keys written to VM.xenstore_data persist in the XAPI database and are rewritten to xenstore on every VM boot, creating a persistent namespace pollution vector.

4. No namespace separation. The xenstore FIST namespace and the file-based FIST mechanism share the same name without any connection, creating confusion about whether xenstore FIST entries have operational effects.

Affected Systems

Directly Affected

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

Indirectly Affected

• XAPI API consumers - tools that read VM.xenstore_data see FIST-prefixed entries and may misinterpret them
• Guest VMs - FIST keys are visible in guest xenstore, potentially confusing guest-side tooling

Exploitation Scenarios

Chaining Analysis

• XSD-2 + XSD-3: A guest domain writes FIST-prefixed keys to vm-data/ (not directly to FIST/), and via bidirectional sync (XSD-3) these values propagate to the XAPI database. If a future code path reads FIST keys from the DB, this creates a guest-to-host injection chain.
• BOC-1 + XSD-2: With root access via BOC-1, an attacker can bulk-inject FIST keys across all VMs in the pool.

Detection

• Monitor VM.xenstore_data for keys with the FIST/ prefix
• Alert on any FIST/ key creation by non-internal sessions
• Audit guest xenstore paths for unexpected FIST entries
• See rule X-02 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VM.xenstore_data records for unexpected FIST/ keys
• Remove any FIST-prefixed entries not set by internal XAPI operations
• Monitor for FIST key writes from vm-admin sessions

Long-Term Fix

Remove FIST from allowed_xsdata_prefixes. The FIST/ prefix serves no legitimate user purpose and should be removed from allowed_xsdata_prefixes at domain.ml:164. If developer testing requires FIST in xenstore, restrict it to _R_LOCAL_ROOT_ONLY via map_keys_roles.

Add map_keys_roles protection. Restrict FIST/* keys to _R_LOCAL_ROOT_ONLY in the VM.xenstore_data field definition.

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

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.