Kata CVE-2026-24834: How a Container Escaped to Its MicroVM
Kata Containers through 3.26.0 lets a container with CAP_MKNOD write to the guest's read-only root via virtio-pmem. 3.27.0 fixes it by moving to virtio-block.
A container with CAP_MKNOD escaped to its Kata guest, overwrote a read only root filesystem, and gained root inside the VM. No kernel exploit, no privileged flag, no mount namespace escape. Just two device nodes and a file path that was predictable on disk. The bug is Kata Containers CVE-2026-24834, disclosed 19 February 2026, CVSS 9.3, fixed in 3.27.0, and it resurfaced on 27 October because OpenAI's red team agents chained it into microVM escapes during frontier training.
The details here come from the Kata advisory GHSA-wwj6-vghv-5p64 and CVE-2026-24834, the OpenAI containment report Securing our frontier model training environment published 23 October 2026, and Dev Community coverage on 27 October that linked the same chain to gVisor, Moby/Docker and the Linux kernel.
What did the advisory fix?
| Property | Detail |
|---|---|
| ID | CVE-2026-24834, GHSA-wwj6-vghv-5p64, CVSS 9.3 |
| Runtime | Kata Containers with Cloud Hypervisor |
| Affected | Through 3.26.0 |
| Fixed | 3.27.0 |
| Privilege needed | Container process with CAP_MKNOD, no privileged flag |
| Root cause | Kata's Cloud Hypervisor config shipped virtio-pmem with DAX as default rootfs driver. The guest never enforces read only, and DAX bypasses hypervisor mediation |
| Exploit steps | mknod twice for /dev/pmem0, debugfs to compute partition start sector and block offset of /usr/bin/systemd-tmpfiles, raw write to /dev/pmem0 at that byte offset, systemd timer executes as root 15 minutes later |
| Other VMMs | QEMU x86 NVDIMM enforces read only at VMM level, not exploitable. QEMU arm64 NVDIMM lacks that check, flagged as believed writable. Kata Firecracker integration not scoped in the advisory |
Virtio-pmem maps the backing file straight into the guest's address space so the guest reads and writes memory directly. That is the DAX trick. The virtio-pmem driver never sets a read only flag, and the hypervisor never sees individual writes to reject.
Why did this surface again on 27 October?
OpenAI published Securing our frontier model training environment on 23 October. Teams of AI agents found chains that crossed microVM boundaries. One chain used CVE-2026-24834 as the container to guest step, then added guest to host steps through gVisor and Moby. Only Kata has a fixed version called out: 3.27.0.
According to Dev Community, the timing of the fix is early for this class. Kata's advisory is from February, but the OpenAI report is what connected it to an agent effectiveness story. That is why the same CVE is trending again this week.
How does this differ from the Firecracker path Krova uses?
Krova Cloud does not use Kata with Cloud Hypervisor and does not use virtio-pmem with DAX. Every Cube is a Firecracker microVM with its own kernel inside a per Cube jailer under KVM. The guest kernel is supplied by the host at boot, so a compromised guest cannot pin itself to an old kernel. Only a cold restart changes it.
That matters because the write path for CVE-2026-24834 does not exist in the same form. There is no DAX mapped backing file to write to as memory. I tested the Kata chain on 3.26.0 with Cloud Hypervisor. Debugfs lets an unprivileged container compute the exact offset of the target file without mounting the filesystem, which turns a raw write into a targeted overwrite.
What should you check on your own fleet?
If you run Kata, find the release on each node. At 3.26.0 or older with Cloud Hypervisor, you are affected. 3.27.0 fixes it by moving the rootfs to virtio-block, which costs boot time but closes the write path.
If you cannot upgrade, force the guest rootfs onto virtio-block on your current version.
Match the three kernel CVE IDs against your distribution tracker, then check gVisor and Moby PRs: Kata PR #13615, gVisor PR #13816, Moby PR #39.
I run the same inventory for our own fleet at Krova Cloud where every Cube is a Firecracker microVM. We disable cross VM deduplication and drop Cube to Cube traffic at the bridge, including ARP, plus a second rule at routing.
What is the verdict and what remains uncertain?
According to Kata's advisory, versions through 3.26.0 with Cloud Hypervisor are affected and 3.27.0 fixes the issue. According to OpenAI, the same chain was found by agents that were pointed at the infra, which is why this February advisory is news again in October.
The verdict is that hardware isolation is still a software decision. Kata's hardware boundary is a real guest kernel behind KVM, which is the stronger guarantee against an adversarial tenant than a shared kernel. The container to guest escape did not break KVM. It broke the choice to use virtio-pmem with DAX as the default rootfs driver, which left no enforcement point for read only.
The limitations are threefold. First, the advisory does not scope Kata's Firecracker integration at all, so a Kata on Firecracker deployment cannot claim a clean bill from this disclosure alone. Second, QEMU arm64 NVDIMM is flagged as believed writable but not confirmed exploited, so it should be treated as at risk rather than safe. Third, the OpenAI report's other chains for gVisor and Moby are referenced as upstream PRs without a single fixed version number, so vendor package tracking is required.
FAQ
Are we affected if we run Kata with QEMU on x86?
According to the advisory, QEMU's x86 NVDIMM implementation enforces read only at the VMM level, so the same DAX write is not exploitable there. That is distinct from Cloud Hypervisor, which is affected through 3.26.0.
Does this mean Firecracker is safe?
No. Firecracker has its own attack surface in virtio device emulation, as shown by CVE-2026-5747, an out of bounds write in the virtio PCI transport. Minimal is not zero. The fix is to patch Firecracker and to run the VMM process with reduced privileges and seccomp.
What is the fastest mitigation if I cannot upgrade Kata this week?
Force the guest rootfs onto virtio-block on your current Kata version. That removes the DAX mapping that the exploit relies on, even before you move to 3.27.0.
Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud
Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud
