Kata Containers EUVD-2026-63432

Exploitation requires: (1) the target Kata Containers deployment must be configured in Confidential Containers mode with genpolicy active - standard Kata deployments without genpolicy are outside the stated scope; (2) the attacker must hold or have compromised host operator-level credentials with the ability to issue CreateContainer API calls to the container runtime - this is not a low-privilege role and represents significant pre-existing access; (3) a target guest container must be scheduled or restarted so the malicious mount/storage rules are applied at container creation time. What limits exploitation: the host operator role is typically restricted to infrastructure administrators; Confidential Computing deployments often include audit logging of orchestration API calls; and the attack window is at container initialization rather than being persistently exploitable against running containers.

The CVSS 8.1 score uses PR:L, which understates the privilege actually required - host operator access in a Kubernetes/OpenShift environment represents substantial pre-existing trust and infrastructure control, making this closer to a PR:H scenario in practice. The AV:N vector is consistent with container orchestration APIs being network-exposed, but the attacker must already be a credentialed host operator, significantly limiting the exposed population. EPSS data was not provided in this advisory, so probabilistic exploitation likelihood cannot be independently assessed. The critical risk signal here is architectural: this vulnerability directly breaks the Confidential Containers threat model, whose entire value proposition is isolating guest workloads from the host. Organizations deploying Kata Containers specifically for Confidential Computing - regulated industries, multi-tenant cloud providers, sensitive government workloads - should treat this as high priority regardless of raw CVSS, because it nullifies a security control they are likely relying upon as a compliance or isolation boundary. No KEV listing or public POC was identified, suggesting exploitation is not yet widespread. No EPSS score was provided, making automated exploitation likelihood assessment impossible from available data.

A malicious or compromised host operator with access to the OpenShift/Kubernetes orchestration plane crafts a CreateContainer request containing a manipulated mount rule that maps an attacker-controlled path over a sensitive location within the confidential guest container's filesystem. When the guest container initializes, it reads attacker-supplied content or exposes confidential data back through the improperly validated mount, breaking the confidentiality and integrity boundary that Confidential Containers are designed to enforce. No public proof-of-concept exploit has been identified, but the attack surface is accessible to anyone with legitimate host operator credentials.