MOKSHA-2026-0079: Network Sharing Bypass via Network.other_config assume_network_is_shared

Advisory IDMOKSHA-2026-0079
Semantic IDNOC-6
Published2026-04-24
CVSS 3.14.1 Medium
CVSS 3.1 VectorAV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L
CVSS 4.05.1 Medium
CVSS 4.0 VectorAV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
XAPI ObjectNetwork
XAPI Fieldother_config:assume_network_is_shared
Entry Rolepool-operator
ResearcherJakob Wolffhechel, Moksha

Affected Products

VendorProductVersions
Citrix / Cloud Software GroupXenServer / Citrix Hypervisorall versions (shared XAPI codebase)
VatesXCP-ng8.3.0

Summary

A pool-operator in XAPI-based hypervisors (XenServer, XCP-ng) can bypass network locality checks by setting assume_network_is_shared=true in Network.other_config. The key is checked at xapi_network_attach_helpers.ml:132-133. When set, XAPI treats the network as shared across all hosts regardless of actual PIF connectivity. This allows VMs to be started on hosts that do not have physical connectivity to the network, causing VIF attachment failures or connectivity loss after VM start. The bypass subverts VM placement safety checks that prevent starting VMs on hosts without the required network infrastructure. The Network.other_config field has no map_keys_roles entries for infrastructure keys.

Vulnerability Description

Network.other_config is a Map(String, String) field defined at datamodel.ml:1998-2007 with ~writer_roles:_R_POOL_OP.

The network sharing check at xapi_network_attach_helpers.ml:130-139:

let assume_network_is_shared ~__context ~network =
  let oc = Db.Network.get_other_config ~__context ~self:network in
  try List.assoc "assume_network_is_shared" oc = "true"
  with Not_found -> false

This check is used during VM placement decisions. When a VM is started, XAPI verifies that the target host has connectivity to all networks required by the VM's VIFs. If assume_network_is_shared=true, this verification is bypassed - the network is assumed to be available on every host.

The consequences of the bypass:

  1. VIF attachment failure. The VM starts but VIF attachment fails because no PIF connects the host to the network. The VM runs without network connectivity on that interface.

  2. Silent connectivity loss. If the VM starts successfully (e.g., some VIFs attach, others fail), the operator may not immediately notice the missing connectivity.

  3. Placement policy subversion. VMs are placed on hosts without the required network infrastructure, violating the pool's network topology constraints.

Root Causes

  1. Missing RBAC protection. Network.other_config has no map_keys_roles entries for infrastructure keys. The assume_network_is_shared key is writable by any pool-operator.

  2. No validation against actual topology. XAPI does not verify whether the network is actually shared when the key is set. The key blindly overrides the topology check.

  3. No logging or alerting. Setting the key produces no warning that network locality checks are being bypassed.

  4. set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks.

Affected Systems

Directly Affected

Indirectly Affected

Exploitation Scenarios

Scenario Impact Pre-conditions Status
VM placement on wrong host VM starts on host without network connectivity, VIF attachment fails pool-operator, non-shared network Source-traced
Silent connectivity loss VM runs with partial network connectivity, not immediately detected pool-operator, multi-NIC VM Modeled
HA restart disruption HA restarts VM on host without required network, connectivity lost pool-operator, HA-protected VM Modeled
BOC-1 chain vm-admin bypasses network locality across all networks via RBAC collapse vm-admin, BOC-1 Source-traced

Chaining Analysis

Detection

Remediation

Short-Term Mitigations

Long-Term Fix

Add map_keys_roles protection. Restrict assume_network_is_shared to _R_POOL_ADMIN in datamodel.ml.

Add topology validation. When the key is set, verify that the network has PIFs on multiple hosts. If not, log a warning that the override is potentially unsafe.

Upstream patches exist. They are held privately pending coordinated disclosure.

Disclosure

Disclosure:

References

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.

Jakob Wolffhechel · Moksha · Copenhagen
jakob@wolffhechel.dk · +45 3170 7337
Published 2026-04-24 08:00 CEST · cna.moksha.dk · shittrix.moksha.dk