CVE-2026-50540 Overview
CVE-2026-50540 is a critical input validation flaw [CWE-20] in Kata Containers, an open source runtime that launches lightweight virtual machines that behave like containers. Versions prior to 4.0.0 accept an arbitrary io.katacontainers.config_path pod annotation and load the referenced host TOML file without restriction. A pod user who can place a file at a host-visible path can supply a configuration that selects an attacker-controlled hypervisor or virtio-fs daemon binary. The runtime then executes that binary as root on the host, breaking the container-to-host isolation boundary. The issue is resolved in Kata Containers 4.0.0.
Critical Impact
An authenticated pod user can achieve root code execution on the Kubernetes host, enabling full node compromise and lateral movement across the cluster.
Affected Products
- Kata Containers versions prior to 4.0.0
- kata-runtime component (all pre-4.0.0 releases)
- Deployments consuming the io.katacontainers.config_path sandbox annotation
Discovery Timeline
- 2026-08-07 - CVE-2026-50540 published to NVD
- 2026-08-12 - Last updated in NVD database
Technical Details for CVE-2026-50540
Vulnerability Analysis
Kata Containers exposes a set of pod annotations that influence runtime behavior. The io.katacontainers.config_path annotation instructs kata-runtime to load a TOML configuration file from a caller-specified path on the host filesystem. The runtime performs no allowlisting, no path validation, and no ownership checks on the referenced file. Any pod user able to stage a TOML file at a host-visible path can redirect the runtime to a configuration under their control.
The loaded TOML defines which hypervisor binary and virtio-fs daemon Kata invokes when starting a sandbox. Because kata-runtime executes on the host as root, the attacker-supplied binary paths run with root privileges outside the container. The result is a direct escape from the container to the host node.
Root Cause
The root cause is the acceptance of an untrusted, tenant-controlled annotation as a source of security-sensitive configuration. The override precedence in load_config placed the pod sandbox annotation above the KATA_CONF_FILE environment variable and the shimv2 create task option. Operator-defined settings could therefore be replaced by pod-supplied values, violating the trust boundary between the container tenant and the host operator.
Attack Vector
An attacker with the ability to create pods and stage files on a host-visible path (for example, through a hostPath volume, a shared storage mount, or writable node directories) crafts a malicious TOML file specifying an attacker-controlled hypervisor.path or virtio-fs daemon. The pod manifest includes the io.katacontainers.config_path annotation pointing to that TOML. When the sandbox starts, kata-runtime loads the malicious configuration and executes the referenced binary as root on the host.
// Security patch: src/libs/kata-types/src/annotations/mod.rs
// The vulnerable annotation key was removed entirely.
/// Prefix for Kata container annotations
pub const KATA_ANNO_CONTAINER_PREFIX: &str = "io.katacontainers.container.";
/// The annotation key to fetch runtime configuration file.
-pub const SANDBOX_CFG_PATH_KEY: &str = "io.katacontainers.config_path";
// OCI section
/// The annotation key to fetch the OCI configuration file path.
Source: Kata Containers commit 03cc670
// Security patch: src/runtime-rs/crates/runtimes/src/manager.rs
// The pod annotation override was removed from the config resolution chain.
/// Config override ordering(high to low):
-/// 1. podsandbox annotation
-/// 2. environment variable
-/// 3. shimv2 create task option
-/// 4. If above three are not set, then get default path from DEFAULT_RUNTIME_CONFIGURATIONS
+/// 1. environment variable
+/// 2. shimv2 create task option
+/// 3. If above two are not set, then get default path from DEFAULT_RUNTIME_CONFIGURATIONS
fn load_config(an: &HashMap<String, String>, option: &Option<Vec<u8>>) -> Result<TomlConfig> {
const KATA_CONF_FILE: &str = "KATA_CONF_FILE";
let annotation = Annotation::new(an.clone());
- let config_path = if let Some(path) = annotation.get_sandbox_config_path() {
- path
- } else if let Ok(path) = std::env::var(KATA_CONF_FILE) {
+ let config_path = if let Ok(path) = std::env::var(KATA_CONF_FILE) {
path
} else if let Some(option) = option {
Source: Kata Containers commit 03cc670
Detection Methods for CVE-2026-50540
Indicators of Compromise
- Pod manifests or admission audit logs containing the io.katacontainers.config_path annotation
- Unexpected TOML files written to host-visible paths such as hostPath volumes or shared node directories
- kata-runtime process spawning hypervisor or virtio-fs daemon binaries from non-standard filesystem locations
- Root-owned processes on the node whose parent is containerd-shim-kata-v2 but whose executable path is outside /opt/kata or the distribution package paths
Detection Strategies
- Audit Kubernetes API server logs for CREATE operations on Pod resources carrying the io.katacontainers.config_path annotation.
- Compare invoked hypervisor and virtio-fs daemon binary paths at runtime against the operator-approved configuration.
- Monitor host filesystem writes into directories that are simultaneously mounted into tenant pods via hostPath.
Monitoring Recommendations
- Enable admission controller policies (OPA Gatekeeper, Kyverno) that reject pods declaring Kata config_path annotations and alert on violations.
- Forward node-level process execution telemetry to a centralized data lake for correlation of kata-runtime child processes against a known-good binary allowlist.
- Track file creation events on hostPath-mounted directories and correlate with pod scheduling events on the same node.
How to Mitigate CVE-2026-50540
Immediate Actions Required
- Upgrade all Kata Containers installations to version 4.0.0 or later, which removes the SANDBOX_CFG_PATH_KEY annotation handling.
- Enforce a cluster-wide admission policy that denies pods carrying any io.katacontainers.config_path annotation until upgrade is complete.
- Restrict pod creation privileges and hostPath volume usage to trusted service accounts only.
Patch Information
The fix is delivered in Kata Containers 4.0.0. Commit 03cc670076099530f4e1e9cb22849afdafb20f65 removes the SANDBOX_CFG_PATH_KEY constant and eliminates the pod annotation from the configuration override precedence in load_config. See the Kata Containers Security Advisory GHSA-mp2j-xm59-qfgw for the maintainer's disclosure.
Workarounds
- Deploy a validating admission webhook that rejects any pod specification containing the io.katacontainers.config_path annotation.
- Set the KATA_CONF_FILE environment variable on nodes to pin the runtime configuration to an operator-controlled file.
- Disable hostPath volumes for untrusted namespaces via PodSecurity admission or equivalent policy engines to prevent tenants from staging malicious TOML files.
# Kyverno ClusterPolicy: block the vulnerable annotation until upgrade
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: block-kata-config-path-annotation
spec:
validationFailureAction: Enforce
rules:
- name: deny-kata-config-path
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Annotation io.katacontainers.config_path is forbidden (CVE-2026-50540)."
pattern:
metadata:
=(annotations):
X(io.katacontainers.config_path): "null"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

