MOKSHA-2026-0040: CHAP Credential Exposure via PBD.device_config

Summary

CHAP authentication credentials for iSCSI storage connections in XAPI-based hypervisors (XenServer, XCP-ng) are stored in PBD.device_config as chapuser (plaintext username) and chappassword_secret (an XAPI secret reference). Any pool-operator can read the PBD record to obtain the chapuser and the secret reference, then call secret.get_value() to resolve the cleartext password. This enables cross-user credential theft: one pool-operator creates an iSCSI SR with CHAP credentials, and a different pool-operator in the same pool recovers the cleartext password via the XAPI secret resolution path. The credentials are also stored in plaintext in the XAPI database (state.db) on disk, accessible via BOC-1 filesystem read.

Vulnerability Description

PBD.device_config is the storage connection string for SM drivers. For iSCSI SRs, it carries CHAP authentication parameters:

• chapuser - stored as plaintext in the PBD record
• chappassword - legacy plaintext password field (still accepted)
• chappassword_secret - reference to an XAPI secret object containing the password
• incoming_chapuser / incoming_chappassword - mutual CHAP credentials

The credential exposure path:

1. pool-operator-A creates an iSCSI SR with CHAP credentials
2. XAPI stores chapuser in plaintext in the PBD record
3. XAPI stores chappassword_secret as a secret reference (e.g., OpaqueRef:abc123)
4. pool-operator-B reads the PBD record: PBD.get_device_config(pbd) returns chapuser and chappassword_secret
5. pool-operator-B calls secret.get_value(OpaqueRef:abc123) to resolve the cleartext password
6. pool-operator-B now has the CHAP credentials for the storage array

The secret resolution path has no ownership check. Any pool-operator can resolve any XAPI secret, regardless of who created it.

Root Causes

1. Plaintext credential storage. CHAP usernames are stored in plaintext in device_config. The password uses a secret reference, but the reference is readable by any pool-operator.

2. Missing secret ownership model. XAPI secrets have no ownership or access control beyond the minimum role for secret.get_value(). Any session with pool-operator can resolve any secret.

3. Cross-user credential access. The RBAC model permits one pool-operator to read credentials created by another pool-operator. There is no per-user or per-SR isolation of credentials.

4. On-disk plaintext storage. The XAPI database (state.db) stores credentials in plaintext. BOC-1 filesystem read (MOKSHA-2026-0001, S2) directly exposes them.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (confirmed on 8.3.0, all checks PASS)

Indirectly Affected

• iSCSI storage arrays (NetApp, Dell EMC, Pure, HPE, etc.) - exposed CHAP credentials enable unauthorized access
• Enterprise storage infrastructure - credential reuse across systems enables lateral movement
• Compliance frameworks - plaintext credential storage violates PCI-DSS, HIPAA, and SOC2 requirements for credential management

Exploitation Scenarios

Chaining Analysis

PDC-4 chains with BOC-1 and PDC-1/PDC-6:

• BOC-1 + PDC-4: vm-admin uses BOC-1 S2 to read state.db from the host filesystem, extracting all CHAP credentials without needing API access.
• PDC-4 + PDC-1: Stolen CHAP credentials (PDC-4) combined with iSCSI target redirection (PDC-1) give the attacker full control over iSCSI sessions.
• PDC-4 + PDC-6: Stolen CHAP credentials (PDC-4) combined with IQN spoofing (PDC-6) enable impersonation of any authenticated iSCSI initiator.

Detection

• Monitor secret.get_value() API calls for unusual access patterns (e.g., pool-operator resolving secrets they did not create)
• Audit PBD records for plaintext chappassword (legacy field that should not be used)
• Monitor for direct reads of state.db from non-XAPI processes
• See rule P-04 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Migrate all CHAP configurations from plaintext chappassword to chappassword_secret
• Restrict pool-operator role grants to a minimum number of trusted administrators
• Monitor secret.get_value() API calls for unauthorized access

Long-Term Fix

Credential isolation. Implement per-user or per-SR secret ownership. A pool-operator should only be able to resolve secrets they created or secrets associated with SRs they manage.

Deprecate plaintext credentials. Reject chappassword (plaintext) in device_config. Require chappassword_secret for all CHAP configurations.

Encrypt state.db credentials. CHAP credentials in the XAPI database should be encrypted at rest, not stored as plaintext.

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

• XAPI source: BaseISCSI.py:181-197 (CHAP credential read from device_config), SRCommand.py:94 (dconf passthrough)
• Thematic advisory: disclosure/advisories/pdc-security-advisory.md (PDC-4)
• Investigation: research/investigations/pbd-device-config.md
• PoC evidence: research/pdc-4/poc/pdc-4-chap-credential-exposure.py (available to CSIRTs on request)

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.