Kata Containers CVE-2026-50540

Exploitation requires two concrete, co-occurring prerequisites drawn from the description: (1) the attacker must be able to set the 'io.katacontainers.config_path' pod annotation on a Kata-managed sandbox (i.e. the ability to create/influence a pod spec), and (2) the attacker must be able to place a file at a host-visible path that the kata-runtime can read, so it can supply a TOML that selects an attacker-controlled hypervisor or virtio-fs daemon binary. Only Kata Containers versions before 4.0.0 are vulnerable, since the annotation was removed in 4.0.0. Limiting factors: this is not exploitable against configurations where untrusted workloads cannot set arbitrary pod annotations (annotation-restricting admission control) or cannot write to any host-visible path; it also depends on the pod running under the Kata runtime class rather than a standard runc runtime.

This is a genuine high-priority isolation-breaking flaw, not a paper-high CVSS. The vendor CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) reflects low-privilege exploitation with a scope change from guest to host and high confidentiality/integrity impact, and root code execution on the host is a worst-case outcome for a sandboxing product. The one meaningful caveat is the compound prerequisite: the attacker must both control the pod annotation AND be able to place a file at a host-visible path, which tempers the raw AV:N rating - in practice this is closer to a local/config-dependent escape than a purely remote network exploit, so I independently assess the attack vector as local (see assessed vector). No EPSS score, KEV listing, or POC was provided, so exploitation probability cannot be quantified; the absence of KEV means there is no evidence of active exploitation. The realistic risk is highest in multi-tenant clusters where untrusted workloads run under Kata and can influence host-visible filesystem paths (e.g. via hostPath-like mounts or shared directories); in single-tenant or fully-trusted-workload environments the practical exposure is lower.

In a multi-tenant Kubernetes cluster running untrusted workloads under Kata Containers, an attacker writes a malicious TOML config and a trojaned hypervisor/virtio-fs binary to a host-visible path (e.g. a shared or hostPath-backed directory), then launches a pod whose spec includes 'io.katacontainers.config_path' pointing at that TOML. When kata-runtime creates the sandbox it loads the attacker's configuration and executes the referenced binary as root on the host, breaking VM isolation and giving the attacker node-level compromise. No public POC is identified, but the attack requires only low privileges and no user interaction once the file can be staged.