CVE-2026-44210 is a critical argument injection flaw (CVSS 9.9) in Kata Containers before 3.31.0. Default settings let a pod creator inject arguments into virtiofsd through pod annotations, which can expose the host root filesystem to the guest. Upgrade to 3.31.0 or later.
What's affected
From the project advisory:
- Affected: Kata Containers 3.29.0 and earlier, as listed by the advisory. The record states all versions before 3.31.0.
- Fixed: 3.31.0.
The vulnerable behavior is in the default configuration. Two pod annotations, one for extra virtiofsd arguments and one for kernel parameters, are on the allowed annotations list out of the box. The runtime checks the annotation name against that list but did not validate the value. Check the advisory and the fix commit if you run a version between 3.29.0 and 3.31.0.
The person who needs access is anyone able to create pods that use the Kata runtime class.
How to check if you're exposed
Check the runtime version on each node:
kata-runtime --version
Then look at the annotation allow list in your Kata configuration file, usually named configuration.toml:
grep -n "enable_annotations" /opt/kata/share/defaults/kata-containers/configuration*.toml /etc/kata-containers/configuration*.toml 2>/dev/null
The path varies by install method. If the list includes the virtio fs extra arguments entry or the kernel parameters entry, pod creators can set them.
What to do now
- Upgrade Kata Containers to 3.31.0 or later on every node.
- Until you do, consider removing the two risky annotations from the allowed list in your Kata configuration. Confirm the effect in a test cluster, since some workloads may rely on them.
- Limit who can create pods with the Kata runtime class, using admission policy and RBAC.
- Review existing pods for annotations that set virtiofsd arguments or kernel parameters.
Why it matters
The class is CWE-88 (argument injection). The runtime started virtiofsd with its own shared directory argument first, then appended whatever the user supplied. Later options in that list can override earlier ones, so a supplied value could change what directory is shared with the guest.
Kata exists to put a stronger boundary between pods and the host. That is why a default setting that lets a pod author choose helper process arguments matters more here than in a plain container runtime. The scope change in the CVSS vector reflects crossing out of the guest.
The record does not mark this CVE as KEV. The lasting lesson is that an allow list of annotation names is not enough when the value is passed to a privileged helper.
Quick check
Does this affect regular runc containers?
The advisory is about Kata Containers. Standard runc pods are not part of it.
Who can trigger it?
A user who can create pods that use the Kata runtime. The record shows low privileges required.
Sources
Last reviewed: 19 October 2026.
