MOKSHA-2026-0020: CBT Metadata Corruption via VDI.other_config content_id

Summary

A vm-admin can corrupt Change Block Tracking (CBT) metadata by injecting a crafted content_id value into VDI.other_config. The content_id key is used by the XAPI storage bridge (storage_smapiv1.ml) to track VDI content identity across activate/deactivate/clone cycles. Incremental backup solutions use content_id to determine the base snapshot for changed-block calculations. A forged UUID causes the backup system to use an incorrect base, missing changed blocks and producing backups that silently lose data on restore. The attack requires a single API call and produces no security alerts.

Vulnerability Description

VDI.other_config is a Map(String, String) field writable by vm-admin. The content_id key participates in a lifecycle managed by the XAPI storage bridge.

content_id Lifecycle

(* storage_smapiv1.ml *)

(* VDI.activate (RW): remove content_id - content is about to change *)
Db.VDI.remove_from_other_config ~__context ~self ~key:"content_id"   (* line 524-525 *)

(* VDI.deactivate: generate new content_id - content is now stable *)
if not (List.mem_assoc "content_id" other_config) then
  Db.VDI.add_to_other_config ~__context ~self ~key:"content_id"
    ~value:Uuidx.(to_string (make ()))                               (* line 557-559 *)

(* VDI.clone: inherit content_id from parent - same content *)
let content_id =
  List.assoc "content_id"
    (Db.VDI.get_other_config ~__context ~self:clonee)                (* line 682-684 *)

Attack Mechanism

The content_id value has no format validation. A vm-admin can:

1. Forge a content_id. Set content_id to match a different VDI's identity. The backup system treats the VDIs as having identical content when they do not, causing the incremental backup to skip blocks that have changed.

2. Remove content_id. Force XAPI to regenerate a new UUID on the next deactivate cycle, breaking the chain of identity that backup systems rely on for incremental tracking.

3. Set an invalid content_id. Inject a non-UUID string that may cause parsing failures in backup systems that expect UUID format.

Impact on Incremental Backups

CBT-based incremental backup works by comparing the current VDI's content_id against the base snapshot's content_id. If they match, the backup system assumes the content is identical and only tracks blocks changed since the snapshot. A forged content_id that matches a stale or incorrect base causes the backup to:

• Miss blocks that changed between the real base and the current state
• Produce a backup that appears valid but is missing data
• Result in silent data loss on restore - the restore completes without error but is incomplete

Root Causes

1. Missing RBAC protection. VDI.other_config has zero map_keys_roles entries for content_id. Any vm-admin can modify it.

2. No format validation. The content_id value is accepted as any arbitrary string. No UUID format enforcement, no check against known VDI identities.

3. Backend trust assumption. The XAPI storage bridge assumes content_id is only modified by XAPI's own lifecycle code. No mechanism distinguishes XAPI-set values from user-injected values.

4. Silent failure mode. Backup systems that rely on content_id for incremental tracking have no way to detect a forged value. The corruption is silent until a restore reveals missing data.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI storage bridge codebase)
• XCP-ng 8.3 - confirmed (live-tested: arbitrary content_id injection)

Indirectly Affected

• Backup systems using CBT - Veeam, Citrix Hypervisor Backup, any XAPI-integrated backup solution that uses content_id for incremental tracking
• Disaster recovery - DR solutions relying on CBT for replication consistency
• Compliance systems - regulatory backups may be silently incomplete

Exploitation Scenarios

Detection

• Monitor VDI.other_config writes for the content_id key from API users (as opposed to internal XAPI operations)
• Alert on content_id values that do not match UUID format
• Audit content_id consistency across snapshot chains: parent and clone should share the same content_id unless modified
• See rule D-04 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VDI.other_config records for unexpected content_id values
• Verify backup integrity by performing periodic full-backup validation (compare full backup against incremental chain)
• Restrict vm-admin role grants for VDIs under CBT-based backup

Long-Term Fix

Add map_keys_roles. Protect content_id in datamodel.ml at _R_POOL_ADMIN to prevent vm-admin from modifying it.

Format validation. Enforce UUID format when content_id is set via the API. Reject non-UUID values.

Internal-only flag. Mark content_id as an internally-managed key that should not be writable through external API calls. The XAPI storage bridge should be the only writer.

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

• Related MOKSHA IDs: MOKSHA-2026-0019 (DOC-1 tapdisk memory pool injection), MOKSHA-2026-0001 (BOC-1 privilege escalation)
• XAPI source: storage_smapiv1.ml:524-525 (content_id removal on activate), storage_smapiv1.ml:557-559 (content_id generation on deactivate), storage_smapiv1.ml:682-684 (content_id inheritance on clone), datamodel.ml (VDI field definition)
• Thematic advisory: disclosure/advisories/doc-security-advisory.md (DOC-4)
• Investigation: research/investigations/vdi-other-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.