CVE-2026-24054: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-24054 is a vulnerability in Kata Containers runtime where a malformed or layer-less container image can cause the host's block device to be incorrectly hotplugged into a guest VM. It affects all versions of containerd-shim-kata-v2 (kata-containers) up to and including 3.25.0, with version 3.26.0 containing the fix. The vulnerability was published on January 29, 2026, and assigned a CVSS v3.1 base score of 10.0 (Critical) and a CVSS v4.0 base score of 8.8 (High) (Kata Advisory, Red Hat CVE).

The root cause is improper validation of the container rootfs type (CWE-754, CWE-1287). When a container image has no layers or is malformed, containerd's overlayfs snapshotter falls back to bind-mounting an empty directory as the container rootfs (containerd overlay.go). The Kata runtime's checkStorageDriver function then incorrectly identifies this bind-mounted path as a block device (returning true instead of false as it would for a normal overlay mount), causing hotplugDrive() to be invoked and the underlying host block device — typically the containerd storage disk — to be hotplugged into the Kata VM (container.go L1122-L1126, container.go L1616-L1623). No authentication or user interaction is required; an attacker only needs the ability to deploy a container using the Kata runtime class with a crafted image.

Successful exploitation causes filesystem-level errors on the host due to double inode allocation, and in most cases results in the host's block device being remounted as read-only, disrupting all services and workloads on the affected node. In the worst case, if the boot disk is affected, this can lead to complete host failure. The vulnerability has a changed scope (S:C in CVSS v3.1), meaning the impact crosses the VM isolation boundary from the container/VM environment to the underlying host system, with high integrity and availability impact (Kata Advisory, Feedly).

1. Reconnaissance: Identify a Kubernetes or container orchestration environment using Kata Containers runtime (version ≤ 3.25.0) with the default overlayfs snapshotter and a Kata RuntimeClass configured (e.g., kata-clh or kata-qemu).
2. Craft malicious image: Build a container image with no filesystem layers — for example, using FROM scratch with no additional instructions — and push it to a registry accessible by the target cluster (e.g., champgoblem/bad-container-image:latest as used in the PoC).
3. Deploy the pod: Submit a Kubernetes Pod manifest specifying the malformed image and the Kata RuntimeClass:

apiVersion: v1
kind: Pod
metadata:
  name: no-layer-image
spec:
  containers:
  - name: no-layer-image
    image: <malformed-image>:latest
    command: ["sleep", "infinity"]
  runtimeClassName: kata-clh

4. Trigger the vulnerability: When containerd processes the image, it falls back to bind-mounting an empty snapshotter directory. The Kata runtime's checkStorageDriver misidentifies this as a block device and calls hotplugDrive(), hotplugging the host's underlying block device (e.g., nvme0n1p1) into the Kata VM.
5. Observe impact: The host filesystem experiences double inode allocation errors (visible in dmesg as EXT4-fs errors), and the host disk is remounted read-only, causing denial of service for all workloads on the node (Kata Advisory).

• Logs (dmesg/kernel): EXT4-fs error messages such as EXT4-fs error (device nvme0n1p1): __ext4_new_inode:1276: comm containerd: failed to insert inode XXXXXXX: doubly allocated? appearing on the host after a Kata container start attempt.
• Logs (Kata/journald): Kata shim log entries matching journalctl -t kata | grep "Block device detected" showing unexpected block device detection for a container using an empty/malformed image, e.g., level=info msg="Block device detected" container=<id> device-path=/dev/root fs-type=ext4.
• File System: Host block device (e.g., /dev/nvme0n1p1 or /dev/sda1) remounted as read-only; write operations to the host filesystem failing with Read-only file system errors.
• Container/Kubernetes: Pod stuck in a failed or pending state with a FROM scratch or otherwise layer-less image, using a Kata RuntimeClass; repeated pod creation attempts with such images.

The primary remediation is to upgrade Kata Containers to version 3.26.0 or later, which sets DEFDISABLEBLOCK := true by default, preventing host block devices from being hotplugged to guest VMs (Kata Commit). As a workaround for systems that cannot immediately upgrade, manually set disable_block_device_use = true in the Kata hypervisor configuration files (e.g., configuration-qemu.toml, configuration-clh.toml). Additionally, implement image validation controls to reject malformed or layer-less container images before they reach the Kata runtime, and restrict who can deploy pods using the Kata RuntimeClass (Kata Advisory, Red Hat CVE).

The vulnerability was reported by security researcher Champ-Goblem and coordinated by Kata Containers maintainers fidencio, danmihai1, and sprt, who published the advisory and patch simultaneously on January 29, 2026 (Kata Advisory). Red Hat acknowledged the issue and tracked it via Bugzilla (Red Hat Bugzilla). The vulnerability received attention from automated CVE tracking services and security aggregators shortly after disclosure, with social media posts on Bluesky noting the issue.