SHShivamNayak11·May 28, 2026Submission
Dirty Frag: a kernel zero-day vs. container and microVM sandboxes
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.
We build declaw.ai — sandboxing infrastructure for AI agents, on Firecracker
microVMs. We run untrusted code we don't write and can't predict, so when
Dirty Frag dropped our first question was: does our isolation boundary hold?
We tested it on a deliberately unpatched kernel. It held. Here's why.
The 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.
Why it matters for multi-tenant platforms: the page cache is shared across
the whole mach
Read the rest
ine. Containers share the host kernel, and namespace isolation,
seccomp, and dropped capabilities are all enforced by that kernel. A kernel
exploit doesn't need to escape the container — it operates below the layer
where container isolation exists. Same structural issue as Dirty COW (2016)
and Dirty Pipe (2022). On the day a zero-day drops, before any patch exists,
every container-based sandbox sharing that kernel is exposed. Patching closes
the window after the fact; it can't close it in advance.
We ran the public PoC (ESP path, CVE-2026-43284) in two environments.
Test 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.
Test 2 — Firecracker microVM (unpatched guest kernel, no seccomp, started as
root with full capabilities — intentionally MORE permissive than test 1). The
exploit worked inside the guest, but every attempt to reach the host
failed: host kernel not visible, host processes invisible (the guest has its
own kthreadd/kswapd), all host ports closed, only virtual block devices, no
host hardware identity. The page cache it corrupted belongs to the guest's
own kernel, mapped to a bounded region of host memory via EPT.
The 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.
If 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.
PoC: https://github.com/V4bel/dirtyfrag
Full writeup (commands + output): https://declaw.ai/blog/dirty-frag-microvm-isolation