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.

Affected: Go: github.com/kata-containers/kata-containers

### Summary

In the runtime-rs standalone virtio-fs path, verified here with QEMU (and verified with Cloud Hypervisor too), Kata Containers runs host `virtiofsd` as root with:

``` --sandbox none --seccomp none ```

If an attacker has root-equivalent execution inside the Kata guest VM, they can send raw FUSE requests directly to the host `virtiofsd`. With the tested runtime-rs virtio-fs configuration, a raw `FUSE_SYMLINK` request whose new symlink name is an absolute host path is honored outside the virtio-fs shared directory.

This lets guest root create host-root owned symlinks in sensitive host paths. The PoC created here will create symlinks in the host `/etc/cron.d` directory, causing host cron to execute a guest-controlled payload as host root.

Impact: guest root can execute code as host root.

### Affected configuration

The verified host used:

``` /opt/kata/share/defaults/kata-containers/runtime-rs/configuration-qemu-runtime-rs.toml

rootless = false shared_fs = "virtio-fs" virtio_fs_daemon = "/opt/kata/libexec/virtiofsd" hypervisor_name = "qemu" debug_console_enabled = false ```

Pinned upstream references, using Kata Containers `main` commit `2ffd1538a296cff93a357bfba0dfca747480a1f8`:

- runtime-rs standalone virtio-fs adds [`--sandbox none --seccomp none`](https://github.com/kata-containers/kata-containers/blob/2ffd1538a296cff93a357bfba0dfca747480a1f8/src/runtime-rs/crates/resource/src/share_fs/share_virtio_fs_standalone.rs#L82-L92) to the `virtiofsd` command li…

Affected: openEuler:24.03-LTS-SP1: kata-containers

This is core component of Kata Container, to make it work, you need a isulad/docker engine. Security Fix(es):

['This vulnerability was fixed in Kata Containers 3.31.0:', 'Description:\n\nIn the runtime-rs standalone virtio-fs path, Kata Containers runs virtiofsd\nas root with --sandbox none --seccomp none.\n\nIf an attacker has root-equivalent execution inside the Kata guest VM,\nthey can send raw FUSE requests directly to the host virtiofsd.\n\nThen, a raw FUSE_SYMLINK request whose new symlink name is\nan absolute host path is honored outside the virtio-fs shared directory.\n\nThis lets guest root create host-root-owned symlinks in sensitive host paths.\n\nCVE: CVE-2026-47243\nGHSA: GHSA-2gv2-cffp-j227\n\nOriginal report:', '---\nAurelien Bombo\nKata Containers Vulnerability Management Team'](CVE-2026-47243)