CVE-2026-47243
CriticalCVSS 9.2Exploitation Probability (EPSS)
Low risk29th percentile - higher than 29% of all known CVEs
Summary
Kata Containers prior to version 3.31.0 is vulnerable to a guest-root to host-root escape in the standalone virtio-fs path. In this configuration, the host virtiofsd runs as root with --sandbox none --seccomp none, allowing an attacker with root access in the guest to bypass the guest virtio-fs client and submit raw FUSE requests to the host virtiofsd, creating symlinks in sensitive host locations such as /etc/cron.d, leading to host code execution as root.
Risk Assessment
An attacker with guest root privileges can gain full control of the host, breaking Kata Containers isolation.
Recommendation
Upgrade Kata Containers to version 3.31.0 or later, which includes the fix.
Other vulnerabilities in Kata Containers
See all- CVE-2026-50540Critical
Kata Containers prior to version 4.0.0 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, allowing a pod user who can place a file at a host-visible path to supply a configuration that selects an attacker-controlled hypervisor or virtio-fs daemon binary, executing code as root on the host.
- CVE-2026-44210Critical
In Kata Containers prior to version 3.31.0, the default configuration allows pod creators to inject arbitrary command-line arguments into the virtiofsd process through the `io.katacontainers.config.hypervisor.virtio_fs_extra_args` pod annotation. By injecting `-o source=/` along with `--no-announce-submounts` and `--sandbox=none`, an attacker can override the virtiofsd shared directory to serve the entire host root filesystem into the guest VM. Combined with the `kernel_params` annotation (also enabled by default) to activate the agent debug console, the attacker can mount the host filesystem from inside the VM and read or write any file on the host, including /etc/shadow.
- CVE-2026-24834Critical
A vulnerability in Kata Containers prior to version 3.27.0 with Cloud Hypervisor allows a container user to modify the guest VM filesystem, leading to arbitrary code execution as root in that VM. The issue does not affect the host or other containers/VMs on the same host, but on arm64 with QEMU lacking NVDIMM read-only support, a guest write could reach the image file.
- CVE-2026-77176High
In Kata Containers, configurations using genpolicy for Confidential Containers guest protection, a malicious host operator can exploit insufficient validation of CreateContainer mount and storage rules, allowing mounting arbitrary container-rootfs paths over sensitive host locations or provisioning arbitrary content.
- CVE-2026-64676Medium
Kata Containers before version 4.0.0 has an authorization bypass vulnerability in confidential-guest memory management. Two ttRPC methods introduced with the mem-agent feature lack the AgentPolicy authorization check, allowing an untrusted host to manipulate guest memory when mem-agent is enabled (off by default). The impact is limited to availability and performance degradation, not memory disclosure or code execution.
- CVE-2026-41326High
A vulnerability in Kata Containers from version 3.4.0 to 3.28.0 allows an untrusted host to write to arbitrary locations inside the guest workload image. This can lead to overwriting binaries in the guest and exfiltrating data from containers, including those running in Confidential VMs (CVMs).
Original NVD description (English source)
Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. Prior to 3.31.0, the runtime-rs standalone virtio-fs path is vulnerable to a guest-root to host-root escape. In this configuration, Kata runs the host virtiofsd as root with --sandbox none --seccomp none, so an attacker with root-equivalent access inside the guest can bypass the guest virtio-fs client entirely by taking over the virtio-fs PCI device and building a virtqueue in userspace to submit raw FUSE requests directly to the host virtiofsd. A crafted FUSE_SYMLINK request whose new symlink name is an absolute host path is honored outside the configured shared directory, allowing guest root to create root-owned symlinks in sensitive host locations such as /etc/cron.d. By pointing such a symlink at a guest-controlled crontab payload reachable through a live runtime process's mount namespace, the attacker causes the host cron daemon to execute that payload as host root, crossing the Kata isolation boundary. This issue is fixed in version 3.31.0.

