Contrast CVE-2025-71422

Exploitation requires the confidential-computing inverse trust model: the attacker must be a malicious or compromised HOST/infrastructure operator able to supply a block device to a Contrast pod VM through Kubernetes. The target pod must have the OPT-IN secure persistent volume (encrypted storage) feature enabled - this is not a default configuration. The Contrast version must be <=1.12.0 bundling cryptsetup <2.8.1, which accepts a LUKS2 header specifying the cipher_null-ecb null keyslot algorithm without error. Limiting factors: no external/remote unauthenticated Internet vector (AV:A, PR:L - host-level provisioning privilege needed), impact is confidentiality-only (data written after the malicious volume is opened), and the fix in 1.12.1 (null ciphers disabled for non-empty passphrases) plus 1.13.0 (detached-header validation and storage integrity protection) closes the primary path.

This is a genuine but conditional confidentiality flaw in a confidential-computing product, best understood through its inverted trust model: the adversary is the untrusted host/infrastructure operator, not a conventional remote attacker. The vendor CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, 6.9 Medium) is well-reasoned - confidentiality-only high impact, no integrity or availability effect, which the advisory explicitly justifies because Contrast persistent volumes were never integrity-protected. My independent CVSS 3.1 estimate (~5.7, AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is consistent. There is NO EPSS score, NO CISA KEV listing, and NO public POC referenced, so all signals point to no observed exploitation. SSVC-style read: exploitation none-observed, automatable no (requires a privileged malicious host in the specific confidential-storage path), technical impact partial (confidentiality only). The real limiter is that exploitation defeats a confidential-computing guarantee rather than a normal network perimeter - it only matters to organizations that (a) run Contrast, (b) enable the secure persistent volume feature, and (c) genuinely distrust their host. For that audience it is a meaningful defeat of the core security promise; for everyone else the practical risk is low. This is a real-priority-for-affected-users issue, not a high-CVSS-low-risk inflation.

A malicious or compromised Kubernetes host provisions a crafted LUKS2 volume using the null keyslot algorithm (cipher_null-ecb) and presents it to a Contrast pod VM that uses the secure persistent volume feature. Because cryptsetup <2.8.1 opens this unauthenticated header without error, the Contrast Initializer wrongly concludes the device is protected, and the guest writes confidential data in plaintext (or under a volume key the host already knows), which the host then reads. No public exploit code is identified at time of analysis.