The Firecracker escape going around this week doesn't contain a Firecracker bug. The guest got out through its network card, and that card is backed by the host kernel.
pwn.ai's write-up is the second half of PwnEscape, CVE-2026-99999. The first half, per iTnews, is a bug in the host's IPv4 path behind virtio-net and TAP, not in Firecracker and not in KVM. A guest makes a deferred checksum write land on an IPv4 header the host already parsed, the header length goes from 20 to 60 bytes, and fragmentation copies 60 bytes out of a buffer that holds 28. That leaks host memory, and the leak grows into read and write.
Part 2 is what you do with that. Starting from host memory, the guest finds the Firecracker process, picks a vCPU thread parked in KVM_RUN, and rewrites the registers that thread will return with. A write to the serial port forces the return, and Firecracker makes a call of the attacker's choosing. The VM stays up.
Where the Boundary Actually Is
I argued last week that your agent sandbox shares a kernel, and that a VM per workload puts a kernel between the job and the host. That's still true for syscalls. It isn't true for devices. Packets from the guest go through TAP into the host's IP stack, so the host kernel is still on the other side of the wire, just through a narrower door.
That's the way to judge a sandbox: by everything the code inside can reach, directly or through something else. On the host kernel side that's TAP and the IP stack. On the VMM side it's the block and serial devices. All of it is input the guest controls.
Why It Landed as Root
pwn.ai ran Firecracker v1.16.1 directly as root, without the jailer. So code execution in the VMM was root on the host. iTnews says that is not how production deployments are meant to run, and it isn't: the jailer puts each VMM in a chroot and its own namespaces, under its own uid, and Firecracker's seccomp filters narrow what that process can call. Whether a jailed setup stops this chain hasn't been shown. A host memory write is a strong primitive, so I wouldn't assume the jailer saves you. I'd assume skipping it hands over root for free.
The Check
On each host that runs microVMs:
Match the kernel against your distro's CVE-2026-99999 advisory. iTnews reports AWS listing kernels 4.4 through 6.18 as affected, with fixes out from Amazon Linux, Debian and Proxmox, and SUSE and Ubuntu still working on it at the end of October. A root in the second command means a VMM running without the jailer's uid drop.
What to Change
- Patch the host and reboot. The fix is in the host kernel, and nothing inside the guest helps. Your sandbox's patch cadence is your host kernel's patch cadence.
- Run every VMM through the jailer, one uid per VM, with Firecracker's default seccomp filters left on. Never as root.
- Keep the host boring. No credentials on it, nothing worth stealing next to the VMs, and hosts you can throw away.
AWS says EC2, Lambda and Fargate are not affected. If you run Firecracker yourself for agents or CI, you're the one who reboots.
The Tradeoff
The jailer is real operational work: chroots, cgroups, a uid per VM, and a launch path you have to own. Reboots cost capacity. And none of it removes the class: as long as the guest's network is backed by the host kernel, the next bug in that path is the next escape.
A VM around an agent is a better patch than a container, and it's still a computer with the host kernel behind its network. I think agents end up in environments built around what they actually need to reach, with far fewer doors behind them. Until then, your sandbox is only as patched as your host.