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

CVE-2026-24834 is a privilege escalation vulnerability in Kata Containers with Cloud Hypervisor, titled "Kata Container to Guest micro VM privilege escalation." It allows a low-privileged container user to modify the guest VM's root filesystem via the /dev/pmem0 device, ultimately achieving arbitrary code execution as root within the Guest micro VM. All versions prior to 3.27.0 are affected (containerd-shim-kata-v2 <= 3.26.0). The vulnerability was published on February 19, 2026. The CVSS v3.1 base score is 8.8 (High) per NVD, while the Kata Containers security advisory rates it 9.3 (Critical) (GitHub Advisory, Kata Advisory).

The root cause is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource) and CWE-281 (Improper Preservation of Permissions). Kata Containers boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and mounting the resulting /dev/pmem* device as the root filesystem. However, the Linux virtio-pmem probe path never marks the NVDIMM region as read-only (nd_region->ro stays cleared), leaving the block device writable with full read/write semantics via pmem_do_write(). Cloud Hypervisor's discard_writes=on option opens the backing file with MAP_PRIVATE, so guest writes modify only a private copy — but because DAX maps the backing file directly into guest memory, a container with CAP_MKNOD (but not CAP_SYS_ADMIN) can create /dev/pmem0, compute file offsets using debugfs, and overwrite arbitrary guest OS binaries or libraries to achieve code execution outside the container namespace. A public PoC is included in the official advisory, demonstrating replacement of /usr/bin/systemd-tmpfiles with a reverse shell (GitHub Advisory, Kata Advisory).

A container user with low privileges (requiring only CAP_MKNOD) can achieve arbitrary code execution as root within the Guest micro VM, resulting in complete compromise of confidentiality, integrity, and availability of the affected VM. The current understanding is that this vulnerability does not impact the security of the host or other containers/VMs running on the same host — the scope is limited to a container-to-guest-VM escape. An important exception exists for arm64 QEMU, which lacks NVDIMM read-only support, meaning a guest write could potentially reach the underlying image file until upstream QEMU gains this capability, potentially enabling persistence (GitHub Advisory, Red Hat Bugzilla).

1. Identify target: Confirm the Kata Containers deployment uses Cloud Hypervisor as the hypervisor and is running a version prior to 3.27.0, where virtio-pmem is used as the VM rootfs driver.
2. Gain container access: Obtain execution within a container running on the vulnerable Kata VM — low privileges suffice, but CAP_MKNOD capability is required.
3. Create pmem device nodes: Inside the container, create block device nodes for the pmem device:

   mknod /dev/pmem0 b 259 0
   mknod /dev/pmem0p1 b 259 1

4. Enumerate filesystem layout: Use debugfs to inspect the guest filesystem on /dev/pmem0p1 without mounting privileges, gathering the partition start sector, sector size, filesystem block size, and physical block index of the target file (e.g., /usr/bin/systemd-tmpfiles).
5. Calculate absolute offset: Compute the absolute byte offset of the target binary within the pmem device: absolute_offset = (partition_start_sectors × sector_size) + (physical_block_index × block_size).
6. Overwrite target binary: Use a Python script or dd to write a malicious payload (e.g., a connect-back shell script) at the computed offset in /dev/pmem0:

   python pmem.py --file /usr/bin/systemd-tmpfiles --write --pattern <hex-encoded-payload>

7. Await execution: Wait for a scheduled timer or service to invoke the replaced binary (e.g., systemd-tmpfiles --clean runs ~15 minutes after boot), triggering the reverse shell as root within the Guest micro VM.
8. Receive shell: Listen for the incoming connection on the attacker-controlled port (e.g., nc -lvp 443) to obtain a root shell on the Guest micro VM (Kata Advisory, GitHub Advisory).

• File System (inside container): Unexpected creation of block device nodes /dev/pmem0 (major 259, minor 0) and /dev/pmem0p1 (major 259, minor 1) within a container namespace.
• File System (guest VM): Unexpected modification timestamps on critical guest OS binaries such as /usr/bin/systemd-tmpfiles, /usr/bin/systemd, or other system executables; file content replaced with shell scripts (e.g., starting with #!/bin/bash).
• Process (guest VM): Unexpected child processes spawned by systemd-tmpfiles or other system services, particularly /bin/bash -i or outbound network connections from system processes.
• Network (guest VM): Outbound TCP connections from the guest VM to unexpected IP addresses and ports (e.g., port 443) originating from system service processes (systemd-tmpfiles, bash).
• Logs (guest VM): Audit log entries showing writes to /dev/pmem0 or /dev/pmem0p1 from non-root container processes; jbd2/pmem0p1 journal entries coinciding with unexpected file modifications.
• Logs (host): Kata agent logs showing unusual device access patterns or unexpected process spawning within the guest VM (Kata Advisory).

Upgrade Kata Containers to version 3.27.0 or later, which resolves the issue by switching the Cloud Hypervisor VM rootfs driver from virtio-pmem to virtio-blk-pci, eliminating the writable DAX-mapped pmem exposure. The fix also explicitly disables NVDIMM for Cloud Hypervisor configurations and adds a runtime guard that overrides any virtio-pmem configuration to virtio-blk for Cloud Hypervisor. No configuration-based workaround is available for versions prior to 3.27.0 — patching is the only remediation. Organizations should inventory all Kata Containers deployments using Cloud Hypervisor and prioritize upgrading immediately (Kata Release 3.27.0, Patch Commit).

The vulnerability was reported by researcher sprt and remediated by fidencio and stevenhorsman from the Kata Containers project. Edera published a technical blog post titled "CVE-2026-24834: When Trusting the Guest Goes Wrong" analyzing the trust boundary implications of the vulnerability. The Hacker Wire covered the vulnerability with an article on the Cloud Hypervisor guest VM root RCE. Red Hat tracked the issue via Bugzilla (Bug 2441025) and published a CVE advisory. Community discussion was observed on Mastodon, LinkedIn, and Bluesky, with general acknowledgment that while the host is not at risk, the container-to-guest-VM escape undermines a key security guarantee of Kata Containers (Red Hat Bugzilla, Edera Blog).