Two different research teams published guest escapes from Firecracker this week, and neither bug lives in KVM. One is in the Firecracker process itself. The other is in the Linux host kernel's IPv4 stack. AWS says Lambda is not affected. If you run Firecracker on your own hosts, that statement does nothing for you.

Firecracker is the microVM monitor behind AWS Lambda and Fargate. It is also what Vercel Sandbox, E2B, Amazon Bedrock AgentCore and DigitalOcean Managed Agents use to run code that an AI agent wrote. That is the context for both disclosures. The thing everyone picked as the safe box for untrusted agent output got opened twice in seven days.

Coinspect: a failed memory discard leaves a hole in the VMM

AWS published bulletin 2026-169-AWS for CVE-2026-122192 on November 4. The affected range is Firecracker v0.23.0 through v1.16.1, which covers roughly six years of releases. The fix is in v1.16.2 and v1.17.0, both published September 10.

The bug needs a specific setup: a microVM restored from a snapshot using the File memory backend, plus a balloon or virtio-mem device. That is a common shape for agent sandboxes, since restoring from a snapshot is how you get cold start times measured in milliseconds, and the balloon is how you claw memory back from idle guests.

Juan Pablo Martinez Kuhn at Coinspect found that when the guest discards memory, Firecracker replaces the file backed pages with anonymous memory using MAP_FIXED. If that replacement fails after the old mapping is already gone, the balloon handler has already marked the request as done and only logs the error. The KVM memory slot stays live. The guest now holds a window onto an address that Firecracker later reuses for its own data. Coinspect pushed guest memory pressure against a memory limit set for each microVM to force the late failure, then read and wrote Firecracker's heap from guest userspace. Root in the guest was required. Guest kernel code was not.

From there they chained a second weakness they call FC-03. Firecracker's seccomp policy allows io_uring_setup, io_uring_register and io_uring_enter in the VMM thread. A fresh ring from inside the compromised VMM could reach a loopback listener on the host, while a direct socket call from the same spot got killed with SIGSYS. With the jailer's network namespace enabled, the same call returned ENETUNREACH. AWS classifies FC-03 as a defense in depth improvement because it requires a prior VMM compromise, and will not assign it a CVE. A seccomp redesign is under review in pull request 6287.

The timeline is the part I'd put on a slide. Firecracker merged the memory discard fix as pull request 6174 on September 1. Coinspect had found the flaw independently but had not yet reported it; they did so September 2 to 4. The pull request description did not mention a security impact. The patched releases shipped September 10 with no advisory attached. The CVE, the GitHub advisory and the AWS bulletin all appeared November 4, two months later. Anyone who upgrades only when the release notes say "security" ran a vulnerable VMM for those two months without knowing it.

pwn.ai: the host kernel trusts the guest's checksum offsets

The second escape never touches Firecracker's code. Paulos Yibelo at pwn.ai found it during Vercel's Sandbox bounty, which ran August 18 to September 1 with a $1 million prize pool. Vercel got 1,285 reports in those two weeks, and 57 were valid. One was rated critical, and this was it.

The bug is CVE-2026-99999, which pwn.ai named PwnEscape. A virtio-net header carries checksum metadata from the guest: where the checksum calculation starts and where to write the result. The host kernel parses the IPv4 header, then later completes the deferred checksum in skb_checksum_help(). Nothing checked that the write landed outside the header it had already validated. Point the offset at the IHL field, flip 0x45 to 0x4f, and the kernel now believes a 20 byte header is 60 bytes long. The fragmenter in ip_do_fragment() copies 60 bytes from a buffer that holds 28, and the 32 extra bytes of host kernel memory leave the box as IP options on an outgoing packet.

That is a 32 byte host memory leak per packet, repeatable, from an unprivileged network write inside the guest. In pwn.ai's own lab it also crashed Linux 6.12 and 7.x hosts, and a chain of 64 byte kernel writes ran a helper as root on the host. Against Vercel's production fleet they demonstrated the leak only, and Vercel says no report reached customer data.

Michael S. Tsirkin at Red Hat wrote the fix, commit 6785011f8b16, "ipv4: validate checksum_start before completing checksum." It went into net.git on October 8 and mainline October 14, and Greg Kroah-Hartman pushed it to stable as 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 and 5.10.272. Tsirkin's own commit message calls it defense in depth and says broader input validation is still needed. Read that as: the virtio checksum API still trusts the guest more than it should, and this patch guards five call sites rather than fixing the design.

Part 2, published November 5, is the Firecracker specific chapter. Yibelo took the kernel write primitive and turned it into code execution inside the Firecracker process on a host running kernel 7.0.0-1011-aws with Firecracker v1.16.1. The chain walks the extended page tables to find the host physical address of a guest page, reverse maps the host page tables to find the Firecracker process and defeat ASLR, locates the saved register frame of a vCPU thread parked in the KVM_RUN ioctl, and rewrites its return path so Firecracker calls a function of the attacker's choosing when the ioctl returns. The guest kept answering SSH afterwards. No kernel oops.

One caveat pwn.ai states plainly: the test host ran Firecracker as root with no jailer. That is not how the project tells you to deploy it, and it is not how AWS deploys it. But I have seen enough "we'll add the jailer later" sandbox services to believe some of them run exactly that way.

Why AWS can say Lambda is fine and you can't

AWS controls both halves of the boundary. They patched their host kernels for the IPv4 bug before disclosure, they do not run Lambda off File backend snapshots with a balloon, and they run the jailer with seccomp and network namespaces. Each of the two escapes needs a condition AWS does not meet. The bulletin's "no customer action is required" is a true statement about one deployment.

If you self host Firecracker, the checklist is short and all of it is overdue:

  • Upgrade to Firecracker v1.16.2 or v1.17.0. If you can't yet, restore snapshots with the Uffd backend instead of File, or drop the balloon device from snapshotted VMs.
  • Patch the host kernel to one of the seven stable releases above or your distro's backport. Updating guest kernels does nothing here. The bug is on the host side of the TAP device.
  • Run the jailer. Turn on the network namespace. Coinspect's FC-03 hop died with ENETUNREACH when it was on.
  • Audit your seccomp filter for io_uring. Pull request 6287 removes io_uring_setup from the default Sync block engine configuration, and you can do that today without waiting for the merge.

The other number from this week is the research cost. pwn.ai says the PwnEscape work ran on under $700 of API tokens with GPT-5.6 Sol doing the reasoning. Coinspect credits Codex with writing their tests and instrumenting Firecracker, and estimates the work would have taken about 20 times longer without it. Finding a hypervisor boundary bug used to be a months long effort by a handful of people. Two teams did it in parallel over a single autumn for less than a mid range laptop.

Sandbox vendors are the obvious next targets, because the sandbox is the one component where a bug is worth a critical bounty and the attacker gets to run arbitrary code inside by design. My prediction: before the end of Q1 2027 we see a third Firecracker or gVisor escape, found by a team using the same tooling, and at least one agent platform discloses that it was running the VMM as root when the report came in.