PwnEscape and agent sandboxes: a microVM is not an absolute boundary
PwnEscape exploits an L2/L3 offset mismatch in virtio-net/TAP to reach the KVM host from a guest, tracked as CVE-2026-99999. It is a reminder that isolating untrusted code in a microVM assumes the host kernel has no reachable path from the guest.

Figure: PwnEscape write-up (source: pwn.ai/blog/pwnescape, captured 2026-10-19)
An agent sandbox usually looks like this: untrusted code runs in a microVM, the VM has a minimal kernel, network egress is filtered, and the host kernel is assumed to be out of reach. PwnEscape breaks the last assumption.
What the bug does
virtio-net hands packets between guest and host. The guest describes a packet with an L2 header offset; the host interprets it in an L3 context. When the two offsets disagree, the host reads or writes outside the intended buffer. From the guest, that is a memory-corruption primitive in the host kernel.
Why agent sandboxes are especially exposed
- They run code the user did not write.
- They usually have network access.
- They are often multi-tenant.
- A single escape compromises every sandbox on the host.
Defender checklist
- Patch the host kernel; treat it as part of the sandbox.
- Keep the guest kernel minimal, but not so minimal that you cannot patch it.
- Restrict egress to an allowlist.
- Use per-sandbox network namespaces.
- Assume escape is possible and limit what the host exposes.
microVM boot path and attack surface
Boot, device setup, virtio queues, and the network backend are all guest-reachable. Each is code. The smaller the device model, the smaller the surface.
seccomp and Landlock
seccomp filters syscalls; Landlock restricts filesystem access. Neither replaces kernel patching, but both raise the cost of a post-escape step.
Egress allowlist
An agent that summarizes documents does not need arbitrary outbound access. A proxy with an allowlist is cheaper than an incident.
Red-teaming your sandbox
Start from inside: assume you have code execution in the guest and try to reach the host. If you cannot, try the device model. If that fails, try the network backend.
Common mistakes
- Treating the microVM as the security boundary and the host as trusted.
- Running the host kernel version that the guest image was built for.
- Allowing egress “temporarily”.
My take
microVMs are good isolation, not absolute isolation. The host kernel is the real boundary, and it needs the same patch discipline as everything else.

Comments
…