What is the CVSS score of CVE-2026-50540?

CVE-2026-50540 has a CVSS 3.1 base score of 9.6 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.4%.

Which versions of Kata Containers are affected by CVE-2026-50540?

Kata Containers kata-runtime versions prior to 4.0.0 contain a critical root code execution vulnerability enabling attackers to escape the guest VM boundary and compromise the host system, completely…. A patch is available.

How to fix or mitigate CVE-2026-50540?

Within 24 hours, inventory all systems running kata-runtime versions below 4.0.0 and classify by exposure to untrusted pod deployments. Within 7 days, execute a coordinated upgrade of all kata-runtime instances to version 4.0.0 or later, prioritizing systems in high-risk environments (multi-tenant clusters, public cloud deployments, or systems running third-party code). Within 30 days, conduct a post-upgrade audit to verify no regression to vulnerable versions and validate that pod annotation policies prevent re-introduction of similar vulnerability patterns.

Kata Containers CVE-2026-50540

EUVD-2026-54679 CRITICAL

Improper Input Validation (CWE-20)

2026-08-07 GitHub_M

RCE Kata Containers

9.6

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.6 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

vuln.today AI

8.8 HIGH

Requires pod-level access plus staging a file on a host-visible path (AV:L/PR:L); yields root code execution across the guest-to-host boundary, so S:C with full C/I/A:H.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Aug 07, 2026 - 22:17 EUVD

Source Code Evidence Fetched

Aug 07, 2026 - 21:36 vuln.today

Analysis Generated

Aug 07, 2026 - 21:36 vuln.today

CVE Published

Aug 07, 2026 - 20:56 cve.org

CRITICAL 9.6

DescriptionCVE.org

Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. Prior to version 4.0.0, kata-runtime is vulnerable to host code execution via an unvalidated configuration path annotation. The runtime accepts an arbitrary io.katacontainers.config_path pod annotation and loads the referenced host TOML file without restriction. As a result, 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, executing code as root on the host. This issue is fixed in version 4.0.0.

AnalysisAI

Host root code execution in Kata Containers kata-runtime prior to 4.0.0 lets a pod user escape the guest VM boundary by abusing the unvalidated 'io.katacontainers.config_path' pod annotation, which caused the runtime to load an arbitrary host TOML configuration file without restriction. Because that config selects the hypervisor and virtio-fs daemon binaries, an attacker who can both set the annotation and drop a file at a host-visible path can point the runtime at an attacker-controlled binary and have it executed as root on the host, collapsing the security isolation Kata exists to provide (CVSS 9.6, scope-changed). There is no public exploit identified at time of analysis, but the fix (removal of the annotation in version 4.0.0) is confirmed by the vendor GHSA advisory and commit.

Technical ContextAI

Kata Containers provides lightweight VMs that behave like containers, integrating with Kubernetes/containerd via a shimv2 runtime to give each pod hardware-virtualization isolation instead of shared-kernel namespaces. The runtime reads its operational parameters - including which hypervisor (e.g. QEMU/Cloud Hypervisor) and which virtio-fs daemon binary to launch - from a trusted host-side TOML configuration file. The root cause is CWE-20 (Improper Input Validation): the runtime honored a user-supplied 'io.katacontainers.config_path' OCI annotation as the highest-priority source for the config file location (ahead of the KATA_CONF_FILE environment variable and the shimv2 create-task option), meaning an untrusted pod could redirect the runtime to a configuration it controls. Since that configuration dictates the paths of privileged host binaries the runtime spawns as root, control over the config equals control over host code execution. The CPE cpe:2.3:a:kata-containers:kata-containers:*:*:*:*:*:*:*:* covers all versions before the 4.0.0 fix, and the commit (03cc670) removes the SANDBOX_CFG_PATH_KEY annotation, the get_sandbox_config_path()/GetSandboxConfigPath() accessors, and the annotation branch in loadRuntimeConfig across both the Go and Rust runtimes.

RemediationAI

Vendor-released patch: upgrade Kata Containers to version 4.0.0 or later, which removes the 'io.katacontainers.config_path' annotation entirely so the runtime can no longer be redirected to an untrusted configuration file (per GHSA-mp2j-xm59-qfgw and commit 03cc670). If you cannot upgrade immediately, apply compensating controls: enforce an admission controller (e.g. Kubernetes OPA/Gatekeeper or Pod Security admission) to reject any pod carrying the 'io.katacontainers.config_path' annotation - the trade-off is that any legitimate but unusual per-pod config-path use will also be blocked; restrict which workloads can write to host-visible filesystem paths by eliminating untrusted hostPath mounts and tightening shared-directory permissions so a pod cannot stage an attacker-controlled TOML/binary where the runtime can read it; and treat all Kata-hosted tenants as untrusted, isolating them to dedicated nodes. These controls reduce but do not fully eliminate exposure, so upgrading to 4.0.0 remains the definitive fix.