CVE-2026-24054 is a maximum severity flaw (CVSS 10.0) in Kata Containers before 3.26.0. When a container image is malformed or has no layers, the rootfs bind mount can be taken for a block device, which gets hotplugged into the guest and can cause host filesystem errors. Version 3.26.0 fixes it.
What's affected
Kata Containers before 3.26.0, with the fix in 3.26.0. The behavior involves containerd's overlay snapshotter and the Kata runtime together. The description says containerd falls back to bind-mounting an empty snapshotter directory when an image is malformed or has no layers.
How to check if you're exposed
On nodes that run Kata:
kata-runtime --version
containerd --version
Check the Kata version on every node, not only in your Helm chart, since nodes can drift. If you install Kata with kata-deploy, check which version it deployed. Then consider who can run workloads: a multi-tenant cluster where untrusted users choose their images is the situation the Kata isolation is meant for, and where this matters most.
What to do now
- Upgrade Kata Containers to 3.26.0 or later on all runtime nodes.
- Restrict which images can run on Kata nodes, using an admission policy that allows only images from your registries.
- Watch nodes for unexpected read-only filesystem remounts or storage errors, which the description lists as a consequence.
- Test the upgrade on a canary node pool first, since it affects the container runtime.
Why it matters
The class is CWE-754, improper check for unusual or exceptional conditions. A well-formed image never reaches this code path. The weak spot is the edge case, an image with no layers, where the runtime made an assumption that does not hold.
Kata is a security boundary product, so a flaw that lets guest activity affect host block devices undermines its main promise. The maximum score reflects a scope change from guest to host. The record does not list this CVE as known exploited, and the description focuses on filesystem errors on the host and the host block device being mounted read-only.
Reading the severity score
The record gives a CVSS base score of 10.0, published 2026-01-29. In the vector, the attacker works over the network, needs no account, and the attack is low in complexity. User interaction is not needed. Impact on confidentiality is no, on integrity high and on availability high.
A base score describes the flaw in general, not your risk. Weigh it against how exposed your instance is and what it can reach. The Gold page for the CVE keeps the score, weakness and references together.
Hardening beyond the patch
Kata Containers exist to add a hardware virtualization boundary between workloads and the host. A flaw that touches the host block device is worth a closer look at how you run it.
Begin with the inventory. List every node that has the Kata runtime installed, the runtime class names that point to it, and the workloads that use those classes. Nodes often differ from the cluster's intended configuration, so read versions from the nodes themselves, using the kata-runtime version command, and compare them with 3.26.0.
Plan the upgrade as a runtime change. Cordon and drain a canary node, upgrade Kata, run a few workloads with typical images, and watch for errors before you roll through the rest. If you use kata-deploy, check how it versions the payload and whether your manifests pin an older image.
Control which images can start on Kata nodes. The trigger in the description is an image that is malformed or contains no layers. Admission policies that allow only images from your own registry, or only signed images, reduce the chance that an odd image arrives. Add a pipeline check that rejects images with zero layers.
Watch the host. The description names filesystem level errors on the host and a host block device that may be mounted read only. Alert on kernel messages about filesystem errors, on nodes that flip to read only, and on unexpected block device activity.
Separate duties. If different tenants share a node, consider dedicating Kata nodes to the workloads that need strong isolation, and keep control plane components elsewhere. That limits what a storage fault on one node can affect.
Last, subscribe to the Kata and containerd security announcements. The description mentions behavior in both projects, so the full picture sometimes spans two release notes.
Find it across your own code
To see which of your packages are affected, the free in-browser dependency scan at gold.safeguard.sh/scan takes a manifest and lists known vulnerabilities. Reachability analysis then helps you judge whether your code calls the vulnerable path, so you can order the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect runc-based containers?
The issue is described for the Kata runtime path. Check the advisory for details on other runtimes.
Why does a malformed image matter?
Because the fallback behavior for an image with no layers produced a bind mount that Kata then treated as a block device.
Sources
Last reviewed: 19 October 2026.
