Constellation Confidential Kubernetes: a LUKS2 volume with a null keyslot cipher is accepted as encrypted

Impact

Constellation treats a LUKS2 persistent volume as confidential if libcryptsetup's crypt_activate_by_passphrase() succeeds with the node's disk-encryption key. cryptsetup before 2.8.1 does not error on a LUKS2 header whose keyslot encryption field is cipher_null-ecb, so a volume that is not actually encrypted can open successfully and be used as if it were. The guarantee the operator bought with a confidential Kubernetes deployment - that state on disk is unreadable to the infrastructure layer - silently does not hold for that volume, and nothing in the node's own logs distinguishes it from a correctly encrypted one. For a GPU cluster running Constellation to keep model weights, datasets or checkpoints out of reach of the host, this means persistent data can sit in plaintext while attestation and the control plane still report a healthy confidential node. Exploitation requires the ability to present a crafted LUKS2 header to the CVM, which is a high-privilege position (CVSS PR:H).

Who can reach it

Local to the node with high privilege - whoever can supply or rewrite the LUKS2 header of a persistent volume presented to the CVM, i.e. the infrastructure or storage layer the confidential-computing model is meant to exclude, not an ordinary cluster tenant. No cluster credentials are needed.

What to do

Upgrade Constellation to v2.24.0, which rejects null keyslot algorithms rather than trusting a successful activation; the fix landed in PR 3927. Because the fix is in the CVM image, rolling it out means replacing node images and cycling nodes - drain and reboot each node onto the new image, which for a GPU cluster is a full rolling node replacement, not a daemon restart. The underlying cryptsetup issue is fixed in cryptsetup 2.8.1, so any other confidential-VM image built on an older cryptsetup carries the same weakness.

References

Related entries

• Podman: podman machine init pulls VM images from an OCI registry without verifying the TLS certificateCVE-2025-6032 · Podman (podman machine init VM image download)High
• Rancher: CLI login with -skip-verify and no --cacert silently accepts any certificateCVE-2025-67601 · RancherHigh
• Kyverno: namespaced policies can read cluster-scoped GlobalContextEntry data from other namespacesCVE-2026-100703 · Kyverno admission controller (globalcontext.Lib CEL library, namespaced policies)High
• Kyverno: a PolicyException meant to exempt one image disables image signature verification for the whole resourceCVE-2026-100704 · Kyverno ImageValidatingPolicy evaluator (PolicyException spec.images / spec.allowedValues ignored)High
• Kyverno: legacy apiCall path skips the egress blocklist, allowing SSRF to cloud metadata from the admission controllerCVE-2026-100705 · Kyverno admission controller (legacy apiCall service executor / GlobalContextEntry)High
• Kyverno: percent-encoded dot-segments in apiCall urlPath bypass namespace scoping in namespaced PoliciesCVE-2026-100707 · Kyverno admission controller (namespaced Policy apiCall urlPath validation)High