Description

Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.7",
  "pubDate": "2026-09-27T02:17:11.040Z",
  "pubdate": "2026-09-27T02:17:11.040Z",
  "executiveSummary": "Contrast versions prior to 1.12.1 contain a critical security vulnerability in the secure persistent volume feature, allowing a malicious host to bypass encryption for confidential containers.\nThe vulnerability stems from the acceptance of crafted LUKS2 volume metadata that specifies the null cipher (cipher_null-ecb) within keyslots, which is processed by the guest VM without sufficient validation.\nBecause the Contrast Initializer incorrectly assumes that a successful cryptsetup operation confirms the presence of valid encryption, the guest VM inadvertently treats the attacker-controlled volume as a secure, encrypted device.\nThis allows a malicious host to force the guest to write sensitive data in plaintext or using an attacker-known key to the persistent storage, directly compromising the confidentiality of the container data.\nThe issue is exacerbated by older versions of cryptsetup that permitted the null cipher, failing to enforce actual encryption for non-empty passphrases.\nSuccessful exploitation requires the attacker to have host-level access to the persistent volume backend to supply the malicious LUKS2 header.\nThe vulnerability represents a failure in the trust boundary between the host and the confidential guest VM, resulting in the exposure of data that is expected to be protected by runtime encryption.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient validation of LUKS2 metadata by the Contrast Initializer and the underlying cryptsetup dependency in versions prior to 2.8.1. The system relies on the assumption that a successful execution of 'cryptsetup open' against a provided volume seed implies that the volume is properly encrypted.\nIn versions before 1.12.1, the Contrast Initializer fails to inspect the underlying cipher parameters requested by the LUKS2 header metadata. Specifically, it does not detect if the 'cipher_null-ecb' algorithm is selected. Because cryptsetup versions older than 2.8.1 accepted this configuration, the guest VM successfully maps the volume as a decrypted device, despite the absence of effective encryption.\nThe attack flow proceeds as follows: 1) A malicious host provides a crafted persistent volume to the pod VM, replacing the expected volume header with a LUKS2 structure specifying the null cipher. 2) When the pod VM initializes the volume, the Contrast Initializer invokes 'cryptsetup open' using the secret seed. 3) The guest's cryptsetup instance, being a vulnerable version, processes the null cipher directive without error. 4) The guest VM proceeds to mount and write data to the volume, believing it is encrypted, while the data is actually written in plaintext or with an attacker-provided key. 5) The host, having full visibility into the persistent volume, retrieves the sensitive data, effectively bypassing the Confidential Computing guarantees.\nThis vulnerability highlights a critical lack of integrity protection for persistent volumes in earlier Contrast versions. The initializer's logic is flawed in its reliance on the exit code of 'cryptsetup open' as an indicator of security posture. The exposure is limited to cases where the attacker maintains control over the host environment, which is the threat model for confidential container runtimes.\nVersions affected include all releases prior to 1.12.1. The remediation in 1.12.1 updates the dependency to cryptsetup 2.8.1, which programmatically disallows the use of null ciphers in keyslots when a passphrase is provided. Furthermore, version 1.13.0 introduced enhanced security measures, including detached-header validation within guest memory and explicit integrity protection, preventing the host from tampering with the volume metadata to downgrade the encryption configuration during the initialization phase."
}