In Kata Containers configurations that use genpolicy for Confidential Containers guest protection, insufficient validation of CreateContainer mount and storage rules allows a malicious host operator to craft CreateContainer requests that cause arbitrary container-rootfs paths to be mounted over host-provided locations (such as /etc/hostname, /etc/hosts, /etc/resolv.conf, Kubernetes/Azure service-account token paths, and other volume mounts), or to provision arbitrary content under /dev/shm and /dev/termination-log. Applications that treat those paths as non-sensitive or guest-only may expose confidential information or accept attacker-controlled input. Standard Kata sandboxing is not affected.

The CVE-2026-50540 has been made public on 2026-07-20, and is part of the Kata Containers 4.0.0

Best Regards -- Fabiano Fidencio

Kata Containers is an open source implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 4.0.0, the kata-agent is vulnerable to an authorization bypass in confidential-guest memory management. In Confidential Containers (CoCo) deployments, the kata-agent enforces an OPA/Rego-based AgentPolicy that must authorize every ttRPC API call, forming the security boundary that prevents an untrusted host from directing the confidential guest. Two ttRPC methods introduced with the mem-agent feature are missing this authorization check, so an untrusted host can invoke them unconditionally regardless of the guest's policy configuration. When mem-agent is enabled (off by default), this lets the host tamper with in-guest memory management by forcing swap, aggressive eviction, or compaction, resulting in attacker-controlled availability and performance degradation of the confidential workload entirely outside the agent-policy boundary. The impact does not include memory disclosure or code execution, and severity is bounded by the precondition that mem-agent must be explicitly enabled. This issue is fixed in version 4.0.0.