CVE-2026-24054
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedKata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. In versions prior to 3.26.0, when a container image is malformed or contains no layers, containerd falls back to bind-mounting an empty snapshotter directory for the container rootfs. When the Kata runtime attempts to mount the container rootfs, the bind mount causes the rootfs to be detected as a block device, leading to the underlying device being hotplugged to the guest. This can cause filesystem-level errors on the host due to double inode allocation, and may lead to the host's block device being mounted as read-only. Version 3.26.0 contains a patch for the issue.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceIn Kata Containers versions prior to 3.26.0, when containerd encounters a malformed container image or one with no layers, it bind-mounts an empty snapshotter directory as the container rootfs. The Kata runtime misidentifies this bind mount as a block device and hotplugs it to the guest, causing double inode allocation on the host filesystem and potentially mounting the host block device as read-only.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 3.26.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify installed Kata Containers versionRun 'kata-runtime --version' or check the kata-runtime binary version. If using a package manager, use 'dpkg -l kata-runtime' or 'rpm -qi kata-runtime'. Compare the version number to 3.26.0.Affected if The installed version is any release prior to 3.26.0 (e.g., 3.25.0, 3.24.0, etc.)
-
Confirm containerd is the container runtimeCheck the runtime configuration in /etc/containerd/config.toml or the runtime class configuration. Look for 'kata' or 'kata-runtime' listed as a runtime.Affected if containerd is configured as the runtime and uses Kata Containers for container execution.
-
Verify snapshotter configurationExamine containerd's snapshotter settings in the config.toml file. Look for the 'snapshotter' directive under the [plugins] section to identify which snapshotter (overlay, native, etc.) is in use.Affected if A snapshotter is configured (any standard snapshotter) - the vulnerability triggers when containerd handles malformed or empty images through any snapshotter.
-
Check for bind mount behaviorReview containerd and Kata runtime logs for entries related to rootfs mount operations. Look for logs indicating 'bind mount' or 'device' detection when containers start with empty or problematic images.Affected if Logs show bind mounts being misinterpreted as block devices, or container creation with empty/malformed images occurs.
-
Inspect for double inode allocation symptomsRun 'df -i' to check inode usage on host filesystem partitions. Compare inode counts before and after spawning containers with Kata runtime.Affected if Inode usage appears abnormally high or increases disproportionately after running containers, suggesting double allocation.
You are affected if Kata Containers version is below 3.26.0 AND containerd is used as the runtime, since the vulnerability triggers when containerd bind-mounts an empty snapshotter directory that Kata misinterprets as a block device.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped3.26.0
Upgrade Kata Containers to version 3.26.0 or later, which contains the patch for this issue.
Kata Containers 3.26.0
- 1. Identify the current Kata Containers version installed by checking the runtime version (e.g., `kata-runtime --version` or examining the Kata shim/virtcontainers packages)
- 2. Review the Kata Containers release notes for version 3.26.0 to understand any specific upgrade requirements or注意事项
- 3. Schedule a maintenance window and back up any critical container workloads and configuration
- 4. Upgrade Kata Containers to version 3.26.0 or later using the appropriate package manager or installation method (e.g., `apt-get update && apt-get install kata-runtime` for Debian-based systems, or follow the official upgrade guide for your distribution)
- 5. Restart the containerd service and any Kata runtime components to ensure the new version is fully loaded
- 6. Verify the installed version is 3.26.0 or later using `kata-runtime --version`
- 7. Test container creation with both normal images and edge cases (malformed images or images with no layers) to confirm the vulnerability is resolved
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation6.0 h
- Testing6.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,992.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-24054 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-24054 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data