Kata Containers
CVE-2026-24834
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain user access inside Kata container
-
DeliveryOpen DAX-mapped /dev/pmem0 rootfs
-
ExploitWrite through unenforced read-only mapping
-
ExecutionModify guest root filesystem
-
ImpactExecute code as root in guest VM
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V13 - Configuration Permission assignment review
|
| Exploitation Conditions | Requires the Kata Containers runtime configured with the Cloud Hypervisor (CLH) backend using the default virtio-pmem/DAX rootfs driver, and an attacker who is already a user inside the container with sufficient permissions to open and write the /dev/pmem0 device (PR:L, local AV:L, no user interaction). Exploitation is LIMITED to the attacker's own guest VM on x86 - the advisory states the host and other VMs/containers are not impacted, and on most platforms persisted writes do not reach the backing image. A notable broadening condition: on arm64 with QEMU, which lacks NVDIMM read-only support, a guest write could reach the underlying image file, increasing impact. Configurations using QEMU with proper NVDIMM read-only support, confidential guests (TDX, which already used virtio-blk), or version 3.27.0+ are not affected. |
| Impact | Signals are mixed and should be weighed carefully. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C, C:H/I:H/A:H, base 8.8) reflects a local, low-complexity attack by a low-privileged container user that crosses a trust boundary (scope change) to full compromise of the guest VM. However, EPSS is only 0.01% (3rd percentile) and the issue is NOT on CISA KEV, indicating no observed widespread exploitation. A GitHub advisory with technical PoC detail exists (publicly available exploit code exists), but PoC availability is distinct from active exploitation. Critically, the impact is bounded: per the advisory's current understanding, the attacker only gains root in their own already-sandboxed guest VM and does NOT compromise the host or neighboring VMs/containers - so on x86 the practical blast radius is the attacker's own sandbox. One important caveat the data flags explicitly: arm64 QEMU lacks NVDIMM read-only support, so on that platform a guest write could reach the underlying image file - verify platform exposure before deprioritizing. Net: real and worth patching, but lower urgency than the 8.8 score alone suggests for x86 Cloud Hypervisor deployments. |
| Exploit ScenarioDerived | An attacker who controls a process inside a Kata-managed container on a Cloud Hypervisor host opens /dev/pmem0 (the DAX-mapped guest rootfs) and writes to it; because the region is never enforced read-only, the writes land in guest memory and are read back, letting the attacker tamper with the guest root filesystem and execute code as root in their micro-VM. Technical PoC detail is published in the GHSA advisory. The attack is local (AV:L) and low-complexity (AC:L) but requires existing low-privilege access inside the container. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv5 – Jun 30, 2026
Privilege escalation in Kata Containers (versions prior to 3.27.0) running on the Cloud Hypervisor backend lets a sufficiently-privileged container user write to the guest micro-VM's root filesystem and gain arbitrary code execution as root inside that VM. The root cause is that the read-only DAX/virtio-pmem rootfs image is never actually enforced read-only, so guest writes to /dev/pmem0 are observed by the guest. Publicly available exploit detail exists (GitHub Security Advisory GHSA-wwj6-vghv-5p64), though EPSS exploitation probability is negligible (0.01%) and it is not on CISA KEV.
Earlier versions of this analysis (4)
Privilege escalation in Kata Containers prior to 3.27.0 when running with the Cloud Hypervisor backend lets a sufficiently-privileged container user write to the DAX-mapped guest root filesystem and gain arbitrary code execution as root inside the guest micro VM. The root cause is that the virtio-pmem region backing /dev/pmem0 is never marked read-only, so guest writes that should be rejected silently succeed. Publicly available exploit details exist via the GitHub Security Advisory (GHSA-wwj6-vghv-5p64), but EPSS is very low (0.01%) and it is not listed in CISA KEV.
Privilege escalation to guest-VM root in Kata Containers prior to 3.27.0 lets a user inside a container modify the file system backing the lightweight micro-VM, ultimately executing arbitrary code as root within that guest VM. The flaw stems from the guest root filesystem image not being reliably enforced as read-only (a CWE-732 permissioning problem) when Cloud Hypervisor is the VMM. A GitHub Security Advisory with exploit details is publicly available, though EPSS is very low (0.01%, 3rd percentile) and there is no public exploit identified beyond the advisory; not listed in CISA KEV.
Privilege escalation to root inside the guest micro-VM in Kata Containers prior to 3.27.0 when paired with the Cloud Hypervisor VMM allows a container user to tamper with the file system backing the Guest VM and execute arbitrary code as root within that VM. Rooted in an incorrect permission assignment (CWE-732) on the guest image backing store, the issue carries CVSS 8.8 with a scope change; publicly available exploit code exists via the GitHub Security Advisory, though EPSS remains very low (0.01%) and it is not listed in CISA KEV. Current vendor understanding is that host and neighboring VM/container isolation is preserved, with an arm64 QEMU caveat noted below.
Permission misconfiguration in Kata Containers.
RemediationAI
Upgrade to Kata Containers 3.27.0, which is the vendor-released patch (commit 6a672503973bf7c687053e459bfff8a9652e16bf); the fix stops using virtio-pmem for the Cloud Hypervisor rootfs and switches to virtio-blk-pci (VMROOTFSDRIVER_CLH changed to virtio-blk-pci, and set_hypervisor_config now coerces a configured pmem rootfs driver to block), so the guest can no longer write through the DAX mapping. Consult the advisory at https://github.com/kata-containers/kata-containers/security/advisories/GHSA-wwj6-vghv-5p64 and apply your distribution's update (SUSE-SU-2026:0757, or the Red Hat VEX at https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-24834.json). If you cannot upgrade immediately, a targeted compensating control is to switch the rootfs driver away from virtio-pmem to virtio-blk (virtio-blk-pci) in the Cloud Hypervisor configuration.toml, which mirrors the upstream fix; note this changes the boot device model and may have minor I/O performance characteristics versus DAX/pmem. Restrict which workloads run on the Cloud Hypervisor backend and avoid the arm64/QEMU NVDIMM path where a guest write could reach the image file, since that variant has greater impact.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Kata Containers boots each pod inside a lightweight VM, DAX-mapping the guest rootfs image from the host directly into guest memory and mounting it as /dev/pmem0. The CWE-732 (incorrect/incomplete permission assignment to a critical resource) flaw arises across three layers: the Linux virtio-pmem driver registers the region as a writable pagemap and never sets nd_region->ro, so nvdimm_check_and_set_ro() is a no-op and the block device stays read/write; Cloud Hypervisor's discard_writes=on intends to make backing writes ineffective via MAP_PRIVATE copy-on-write, but the guest still reads back its own modified private pages; and because DAX maps the file directly into guest memory, the hypervisor cannot intercept or reject individual stores. The CPE cpe:2.3:a:katacontainers:kata_containers confirms the affected component is the Kata runtime, specifically the runtime-rs Cloud Hypervisor convert path that selected virtio-pmem (PmemConfig) for the standard guest image.
Know when Kata Containers gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Local container user (AV:L, PR:L) escalates across the container-to-VM boundary (S:C) to full root control of the guest (C:H/I:H/A:H); matches vendor scoring of 8.8.
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
9DescriptionNVD
Kata 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.27.0, an issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understanding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file). Version 3.27.0 patches the issue.
Executive ViewAI
Kata Containers versions prior to 3.27.0 contain a privilege escalation vulnerability enabling container users to bypass isolation and gain root-level access within guest virtual machines, with publicly available exploit code already disclosed. This directly undermines the container isolation guarantees that organizations depend on for multi-tenant security and workload separation. Immediate patching is required to restore security boundaries.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Affected Products (CPE)NVD
More in Kata Containers
View allSandbox escape in Kata Containers allowing guest VM to access host resources. CVSS 10.0 — undermines the core security g
An issue was discovered in Kata Containers through 1.11.3 and 2.x through 2.0-rc1. Rated high severity (CVSS 8.8), this
Arbitrary file write in Kata Containers v3.4.0 to v3.28.0 allows untrusted hosts to overwrite binaries and exfiltrate da
Host root code execution in Kata Containers kata-runtime prior to 4.0.0 lets a pod user escape the guest VM boundary by
An improper file permissions vulnerability affects Kata Containers prior to 1.11.5. Rated high severity (CVSS 7.1), this
Authorization bypass in the kata-agent's ttRPC API allows an untrusted host to invoke two mem-agent methods unconditiona
Vendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
GHSA-wwj6-vghv-5p64
NVD
CVE.org
EPSS
VulDB
Exploit-DB