MOKSHA-2026-0086: License Expiry Manipulation via Host.license_params expiry

Summary

An attacker with root access on an XAPI-based hypervisor host (XenServer, XCP-ng) can set the expiry key in Host.license_params to "never" or a far-future date, preventing license expiry enforcement and suppressing expiry alerts. The license_check.get_expiry_date function at license_check.ml:28-37 reads the expiry value and treats "never" as no expiration. The Host.license_params field has the strongest access control in the XAPI RBAC system: _R_LOCAL_ROOT_ONLY with pool_internal:true. Like LPC-1, this is a license compliance issue requiring local root - an attacker at that privilege level already has full system control.

Vulnerability Description

Host.license_params is a Map(String, String) field defined at datamodel_host.ml:3055-3059 with DynamicRO qualifier. The sole write method (set_license_params) requires _R_LOCAL_ROOT_ONLY and is not exposed via the external API.

The expiry key is consumed by two systems:

License check gate (license_check.ml:28-47):

license_check.get_expiry_date reads "expiry" from license_params
    |
    v
"never" -> no expiry (VM operations proceed)
date string -> parsed via Clock.Date.of_iso8601
    |
    v
license_check.check_expiry compares against current time
    |
    v
If expired -> raises license_expired API error
    |
    v
Called before VM operations (license_check.vm at line 49-52)

Daily license check daemon (daily_license_check.ml:27-35):

daily_license_check.get_info_from_db reads license_params
    |
    v
Checks expiry dates against current time + 30 day warning window
    |
    v
Generates license_expires_soon or license_expired alerts

An attacker with root access can modify the XAPI database to set expiry="never" or expiry="2099-12-31T23:59:59Z". This prevents the license check gate from blocking VM operations and suppresses the daily license expiry alerts.

Root Causes

1. No integrity verification. XAPI does not verify that the expiry value was set by the legitimate v6d license daemon. Database modification is accepted without authentication.

2. "never" as valid expiry. The license_check.ml code treats "never" as a valid expiry value, which is the intended behavior for perpetual licenses but also the simplest manipulation target.

3. Root access prerequisite. The sole attack path requires local root, which already grants full system control.

Affected Systems

Directly Affected

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

Indirectly Affected

• License compliance systems - expiry enforcement is bypassed
• Vendor licensing revenue - expired licenses continue to function

Exploitation Scenarios

Chaining Analysis

• BOC-1 + LPC-2: BOC-1 provides filesystem access enabling XAPI database modification. However, root access via BOC-1 already grants complete system control. License expiry bypass is the least of the security concerns at that privilege level.
• SMC-1: No interaction. License parameters do not touch storage protocol traffic.
• No meaningful escalation identified. License expiry manipulation provides no security-relevant capability beyond what root access already grants.

Detection

• Monitor for unexpected changes to Host.license_params:expiry values
• Alert on expiry dates changing to "never" or dates far in the future
• Compare license_params expiry against the expected license terms
• No API-level monitoring needed (field is not API-accessible)

Remediation

Current State (Adequate)

The current security posture is adequate:

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

Optional Hardening

Add integrity verification. Sign license_params data so XAPI can verify it was produced by the legitimate v6d daemon.

Add database integrity checks. Verify that license_params values have not changed between XAPI restarts without a corresponding v6d daemon update.

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-0085 (LPC-1)
• XAPI source: datamodel_host.ml:3055-3059 (Host.license_params field definition), datamodel_host.ml:2047-2067 (set_license_params), license_check.ml:28-37 (expiry date parsing - treats "never" as no expiry), license_check.ml:39-47 (check_expiry), daily_license_check.ml:27-35 (daily expiry alert check)
• Thematic advisory: disclosure/advisories/lpc-security-advisory.md (LPC-2)
• Investigation: research/investigations/host-license-params.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.