MOKSHA-2026-0041: Rolling Upgrade State Injection via Pool.other_config

Summary

A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can inject a fake rolling upgrade state by writing the rolling_upgrade_in_progress key to Pool.other_config. The mere presence of this key - regardless of value - causes helpers.ml:718-719 to return true, disabling version compatibility checks, altering pool behavior during operations, and preventing detection of version mismatches across the pool. The key has no map_keys_roles protection and no write-time validation, and with BOC-1 chaining, a vm-admin can reach this vector via RBAC collapse.

Vulnerability Description

Pool.other_config is a Map(String, String) field writable by pool-operator. The rolling_upgrade_in_progress key controls whether the pool operates in rolling upgrade mode - a transient state intended for use only during actual version upgrades.

The code path:

1. pool-operator calls Pool.add_to_other_config(pool, "rolling_upgrade_in_progress", "") (any value works)
2. helpers.ml:718-719 checks List.mem_assoc "rolling_upgrade_in_progress" - a pure presence check
3. The function returns true regardless of the key's value
4. Multiple consumers alter behavior:
   • db_gc.ml:161-163 - triggers rolling upgrade resynchronization
   • xapi_host_helpers.ml:624-625 - disables software version checking during pool join
   • xapi-autostart-vms script - suppresses VM auto-start

No validation occurs at write time. The key is not protected by map_keys_roles. The Pool.other_config field only protects UI keys (folder, XenCenter.CustomFields.*, EMPTY_FOLDERS) at _R_VM_OP.

Root Causes

1. Missing RBAC protection. Pool.other_config has zero map_keys_roles entries for infrastructure keys. The rolling_upgrade_in_progress key inherits the class default _R_POOL_OP.

2. Presence-only check. The consumer at helpers.ml:718-719 uses List.mem_assoc - the key's mere existence triggers upgrade mode. There is no validation of expected values, no cross-check against actual upgrade state, and no timestamp or session binding.

3. Missing write-time validation. No mechanism verifies that a rolling upgrade is actually in progress before accepting this key.

4. Insufficient logging. No security-level log event is generated when this key is written.

Affected Systems

Directly Affected

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

Indirectly Affected

• All hosts in the pool - version compatibility checks are bypassed, allowing mismatched hosts to join
• VM auto-start systems - auto-start suppressed during fake upgrade state
• Pool join operations - hosts with incompatible software versions can join the pool

Exploitation Scenarios

Chaining Analysis

• BOC-1 + PLOC-1: vm-admin uses BOC-1 S3 (RBAC collapse) to self-grant pool-operator, then writes the rolling_upgrade_in_progress key to disable version checks across the pool. Effective minimum role with BOC-1: vm-admin.
• PLOC-1 + pool join: After injecting fake upgrade state, hosts with incompatible software versions can join the pool. This can cause operational failures when the fake upgrade state is removed and version mismatches are detected.

Detection

• Monitor Pool.other_config for the rolling_upgrade_in_progress key outside of actual upgrade operations
• Alert on presence of this key when no RPU (Rolling Pool Upgrade) is in progress
• Compare against XAPI task list for legitimate upgrade tasks
• See rule PL-01 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit Pool.other_config for unexpected rolling_upgrade_in_progress keys
• Restrict pool-operator role grants to trusted administrators
• Monitor for the key's presence outside of planned upgrade windows

Long-Term Fix

Protect the key via map_keys_roles. Add rolling_upgrade_in_progress to Pool.other_config map_keys_roles at _R_LOCAL_ROOT_ONLY or _R_POOL_ADMIN in datamodel_pool.ml. This key should only be set by internal XAPI upgrade orchestration, not by API users.

Add state validation. The consumer at helpers.ml:718-719 should cross-check against actual upgrade state (e.g., verify that an RPU task exists) rather than relying solely on a user-writable key.

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: helpers.ml:718-719 (presence check), db_gc.ml:161-163 (resynchronization consumer), xapi_host_helpers.ml:624-625 (version check bypass), datamodel_pool.ml:1764-1773 (field definition)
• Thematic advisory: disclosure/advisories/ploc-security-advisory.md (PLOC-1)
• Investigation: research/investigations/pool-other-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.