MOKSHA-2026-0085: Feature Restriction Bypass via Host.license_params restrict_* Keys

Summary

An attacker with root access on an XAPI-based hypervisor host (XenServer, XCP-ng) can modify the XAPI database to set all restrict_* keys in Host.license_params to "false", enabling licensed features (GPU passthrough, dynamic memory control, workload balancing) without a valid license. The Host.license_params field has the strongest access control in the XAPI RBAC system: _R_LOCAL_ROOT_ONLY with pool_internal:true and DynamicRO qualifier. The setter is not exposed via the external API. This is a license compliance issue, not a traditional security vulnerability - an attacker with root access already has full system control. The finding is included for completeness as part of the systematic XAPI map field audit.

Vulnerability Description

Host.license_params is a Map(String, String) field defined at datamodel_host.ml:3055-3059 with DynamicRO qualifier. The set_license_params method at datamodel_host.ml:2047-2067 is marked pool_internal:true, hide_from_docs:true, and allowed_roles:_R_LOCAL_ROOT_ONLY. This is the most restrictive access level in XAPI.

The restrict_* keys are consumed by the pool features system:

Host.license_params:restrict_* values
    |
    v
pool_features_helpers.ml:42-51 reads restrict_* keys from all hosts
    |
    v
pool_features_helpers.ml:75-107 computes intersection of features
    |
    v
Pool.restrictions updated with pool-level feature flags
    |
    v
pool_features.ml:28-30 checks features before operations
    |
    v
Feature-gated operations allowed/denied

An attacker who has obtained root access on the host can modify license_params values directly in the XAPI database on disk. Setting restrict_dmc=false, restrict_gpu=false, restrict_wlb=false (and other restrict_* keys) enables the corresponding features at the pool level after the next update_pool_features cycle.

Live host verification confirms the field is not accessible via the external API: attempts to write via xe CLI or XAPI session return "Internal API call attempted with non-pool session".

Root Causes

1. No value validation in setter. The set_license_params method accepts any map content without validating that restrict_* keys contain only "true" or "false".

2. No integrity verification. XAPI does not verify that license_params data was produced by the legitimate v6d license daemon. Direct database modification is indistinguishable from daemon-written values.

3. Root access prerequisite. The sole attack path requires local root on the host, which already grants full system control. License enforcement is redundant at that privilege level.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (XCP-ng uses free edition by default, reducing relevance)

Indirectly Affected

• License compliance systems - feature usage reporting is invalidated
• Vendor licensing revenue - licensed features used without payment

Exploitation Scenarios

Chaining Analysis

• BOC-1 + LPC-1: BOC-1 provides root-equivalent host filesystem access, enabling direct XAPI database modification. However, an attacker with BOC-1 root access has full system control - license enforcement bypass provides no additional security-relevant capability. The attacker can directly invoke hypervisor commands bypassing XAPI entirely.
• SMC-1: No interaction. Host.license_params does not touch storage protocol traffic or sm-config values.
• No meaningful escalation identified. The _R_LOCAL_ROOT_ONLY + pool_internal access model is the strongest protection in XAPI. License restriction bypass is a compliance concern at root level, not a security escalation.

Detection

• Monitor for unexpected changes to Pool.restrictions (downstream of license_params)
• Alert on licensed features becoming available without corresponding license application
• No API-level monitoring needed (field is not API-accessible)

Remediation

Current State (Adequate)

The current security posture is adequate for the threat model:

1. Write access is maximally restricted (_R_LOCAL_ROOT_ONLY + pool_internal)
2. The field is DynamicRO - no auto-generated map mutation methods
3. Values are computed internally by the v6d license daemon

Optional Hardening

Add value validation. Validate that restrict_* keys contain only "true" or "false" in set_license_params.

Add integrity verification. Sign license_params data so XAPI can verify it was produced by the legitimate v6d daemon. This is defense-in-depth against direct database modification.

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

• Related MOKSHA IDs: MOKSHA-2026-0086 (LPC-2)
• XAPI source: datamodel_host.ml:3055-3059 (Host.license_params field definition), datamodel_host.ml:2047-2067 (set_license_params - _R_LOCAL_ROOT_ONLY, pool_internal), pool_features_helpers.ml:42-51,75-107 (feature computation from license_params), pool_features.ml:28-30 (feature enforcement)
• Thematic advisory: disclosure/advisories/lpc-security-advisory.md (LPC-1)
• Investigation: research/investigations/host-license-params.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.