{"slug": "dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes", "title": "Dirty Frag: a kernel zero-day vs. container and microVM sandboxes", "summary": "On May 7, security researcher Hyunwoo Kim disclosed Dirty Frag, two Linux kernel vulnerabilities (CVE-2026-43284 and CVE-2026-43500) that grant unprivileged users deterministic root access on most Linux distributions since 2017, with Microsoft confirming active exploitation the next day. The exploit, a page-cache write primitive, bypasses container isolation by operating below the kernel layer where namespace and seccomp protections exist, exposing all container-based sandboxes sharing the host kernel before any patch is available. Testing showed the exploit achieved root in a Docker container within two seconds, but failed to escape a Firecracker microVM due to hardware-enforced isolation via EPT, highlighting that kernel-level vulnerabilities cannot reach the host when the kernel is not shared.", "body_md": "On May 7, Hyunwoo Kim (V4bel) disclosed Dirty Frag — two Linux kernel vulnerabilities (CVE-2026-43284 and CVE-2026-43500) that give unprivileged users deterministic root on most Linux distributions shipped since 2017. Microsoft confirmed active exploitation the next day.\n\nWe build declaw.ai — sandboxing infrastructure for AI agents, on Firecracker\nmicroVMs. We run untrusted code we don't write and can't predict, so when\nDirty Frag dropped our first question was: does our isolation boundary hold?\nWe tested it on a deliberately *unpatched* kernel. It held. Here's why.\n\nThe exploit is a page-cache write primitive: it tricks the kernel into overwriting the in-memory contents of any file (/usr/bin/su, /etc/passwd) and gives root. Fully deterministic, no race.\n\nWhy it matters for multi-tenant platforms: the page cache is shared across\nthe whole machine. Containers share the host kernel, and namespace isolation,\nseccomp, and dropped capabilities are all enforced *by* that kernel. A kernel\nexploit doesn't need to escape the container — it operates below the layer\nwhere container isolation exists. Same structural issue as Dirty COW (2016)\nand Dirty Pipe (2022). On the day a zero-day drops, before any patch exists,\nevery container-based sandbox sharing that kernel is exposed. Patching closes\nthe window after the fact; it can't close it in advance.\n\nWe ran the public PoC (ESP path, CVE-2026-43284) in two environments.\n\nTest 1 — container sandbox (Docker, seccomp on, unprivileged uid=1001, host kernel 6.8.0): unprivileged user to root in under 2 seconds. Seccomp was active but didn't help — the required syscalls were permitted by the profile. With root we read /etc/shadow, host kernel boot params, and Docker overlay2 paths.\n\nTest 2 — Firecracker microVM (unpatched guest kernel, no seccomp, started as\nroot with full capabilities — intentionally MORE permissive than test 1). The\nexploit worked *inside* the guest, but every attempt to reach the host\nfailed: host kernel not visible, host processes invisible (the guest has its\nown kthreadd/kswapd), all host ports closed, only virtual block devices, no\nhost hardware identity. The page cache it corrupted belongs to the guest's\nown kernel, mapped to a bounded region of host memory via EPT.\n\nThe asymmetry is the point: the microVM started with more privilege than the container and still couldn't reach the host. What matters isn't what permissions the software grants — it's whether the kernel is shared. To escape Firecracker you'd need a bug in the VMM (~50K lines of Rust) or KVM; Google's kvmCTF pays $250K for a guest-to-host escape and only one has ever been publicly demonstrated.\n\nIf you run untrusted code multi-tenant, the question for any isolation provider: if code inside the sandbox becomes root, can it reach the host or other tenants? If the answer is \"as long as we're patched\" — that's the gap.\n\nPoC: https://github.com/V4bel/dirtyfrag Full writeup (commands + output): https://declaw.ai/blog/dirty-frag-microvm-isolation\n\nComments URL: [https://news.ycombinator.com/item?id=48304227](https://news.ycombinator.com/item?id=48304227)\n\nPoints: 1\n\n# Comments: 0", "url": "https://wpnews.pro/news/dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes", "canonical_source": "https://news.ycombinator.com/item?id=48304227", "published_at": "2026-05-28 03:43:38+00:00", "updated_at": "2026-05-28 03:56:19.041540+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-agents"], "entities": ["Hyunwoo Kim", "V4bel", "Microsoft", "declaw.ai", "Firecracker", "Docker", "CVE-2026-43284", "CVE-2026-43500"], "alternates": {"html": "https://wpnews.pro/news/dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes", "markdown": "https://wpnews.pro/news/dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes.md", "text": "https://wpnews.pro/news/dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes.txt", "jsonld": "https://wpnews.pro/news/dirty-frag-a-kernel-zero-day-vs-container-and-microvm-sandboxes.jsonld"}}