Firecracker 0.23.0 to 1.16.1: guest root reaches VMM process memory after a failed memory discard on snapshot restore (CVE-2026-122192); fixed 1.16.2 and 1.17.0

View raw markdownEdit on GitHub ↗

TL;DR

AWS's bulletin 2026-169 and the Firecracker advisory GHSA-48ww-rqpp-2mgm (both 2026-11-04) say a root user inside a guest can read and modify the memory of the Firecracker process on the host when the microVM was restored from a snapshot with the File memory backend, has a balloon or virtio-mem device, and a memory discard fails to be re-mapped under host memory pressure. Coinspect, who found it, reached controlled code execution in the VMM from guest userspace with root. The fix shipped on 2026-09-10 in 1.16.2 and 1.17.0 as a bugfix (PR #6174, merged 2026-09-01, no security wording) and was given a CVE eight weeks later. If your agent sandbox restores Firecracker snapshots, upgrade; if you cannot, restore with the Uffd backend. AWS says Lambda and its other services are not affected.

What happened

The mechanism, from the advisory. When a guest asks the balloon or virtio-mem device to discard memory, Firecracker replaces the discarded range with a fresh mapping. If that replacement fails, which the advisory ties to specific host memory conditions, the affected part of the guest memory range stays unmapped while Firecracker keeps running, and memory Firecracker later allocates in that range becomes reachable from the guest. The patch keeps the original mapping's MAP_NORESERVE flag on the replacement and, if the replacement still fails, terminates the process and its VM rather than continuing with an invalid mapping. CWE-390 and CWE-825. VMs started without a snapshot, or restored with the Uffd memory backend, are not affected.

What the researcher demonstrated. Coinspect's post (Juan Pablo Martinez Kuhn, last updated 2026-11-04) says the guest-userspace proof of concept needed root in the guest and no code in the guest kernel; the guest had to consume headroom under a per-microVM memory limit to make the late mapping fail; the result was reading and modifying live Firecracker host-process memory and controlled code execution in the VMM. A separate guest-kernel variant reached a host-kernel path that panicked a host carrying an unrelated Linux kernel flaw the post identifies by id; host-kernel code execution was not attempted. A second finding, FC-03, lets code already running in the VMM use io_uring to perform operations the seccomp policy blocks (a loopback network connection and filesystem changes were demonstrated, inside the jailer's chroot and namespaces). AWS classifies FC-03 as defense in depth because it needs a prior VMM compromise, plans no CVE for it, and has a seccomp redesign under review as PR #6287.

Timeline. 2026-08-25 Coinspect preserves first evidence. 2026-08-27 to 28 guest-kernel proof of concept. 2026-09-01 PR #6174 merged, described as a virtio-mem snapshot-restore fix. 2026-09-02 to 04 report to AWS. 2026-09-10 v1.16.2 and v1.17.0 released; their notes say unplugged memory "could stay writable by the VMM and potentially unmapped" after restore and that Firecracker now aborts if the re-map fails, with no security label. 2026-09-17 to 27 the escape is reproduced from guest userspace with root; the patched release stops it. October: AWS confirms the escape as a security issue. 2026-11-04 the CVE record (AWS CNA, 19:35 UTC), the GHSA and bulletin 2026-169 are published. Scores: CVSS 3.1 7.5 (AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) and CVSS 4.0 7.1 from AWS.

Why it is in this corpus. Firecracker is the microVM under a large share of the "run the agent's code in a sandbox" products. Coinspect's post names AWS Lambda and Fargate, Amazon Bedrock AgentCore, DigitalOcean Managed Agents, Vercel Sandbox and E2B as users, and says the research examined Firecracker itself and did not assess those deployments. Snapshot restore is exactly the feature such services use to start a sandbox fast, and the balloon is how they reclaim memory between runs. A sandbox that runs model-written code is a sandbox whose guest is attacker-controlled by design, and root inside it is the default for most code-execution sandboxes. This corpus tracks Vercel's own Firecracker guest-to-host bounty findings for the same reason.

Two facts to keep apart. The fix date is 2026-09-10 and the disclosure date is 2026-11-04. An operator who pinned 1.16.1 and read release notes for security items had nothing to act on for eight weeks. The ranges on all three vendor documents agree (0.23.0 through 1.16.1, inclusive); the CNA record writes it as 0.23.0 before 1.16.2.

Am I affected?

  1. Version. firecracker --version. Anything from 0.23.0 through 1.16.1 is in range. In the supported lines, 1.16.0 and 1.16.1 are the affected releases.
  2. Configuration. You are exposed only if all three hold: the VM is restored from a snapshot (PUT /snapshot/load), the restore uses the File memory backend (mem_backend.backend_type: File, or the legacy mem_file_path), and the VM has a balloon or virtio-mem device. Fresh boots and Uffd restores are not affected.
  3. Hosted sandboxes. If you consume a sandbox product rather than run Firecracker, ask the vendor whether it restores from snapshots with the File backend and which Firecracker version it runs. AWS states its own services are not affected. Other named vendors had published nothing this sweep could find on 2026-11-05.

If you are affected

  • Upgrade to Firecracker 1.16.2 or 1.17.0 or later. Note that 1.16.2 bumps the snapshot format version, so snapshots taken with 1.16.0 or 1.16.1 do not load; plan a re-snapshot.
  • If you cannot upgrade yet, restore snapshots with the Uffd memory backend and follow its documented requirements for discarded pages.
  • Host-side measures the advisory lists as risk reduction, not a fix: heuristic overcommit (vm.overcommit_memory=0) on kernels without the Linux 6.12 overcommit change, keep each VM's guest memory including any virtio-mem region no larger than host RAM plus swap, keep the OOM killer enabled for Firecracker's memory cgroup.
  • Operators maintaining forks should pick up PR #6174 and its 1.16 backport PR #6178.
  • Treat a VMM compromise as a host compromise for the credentials the Firecracker process can reach. Rotate per rotating cloud credentials if a guest you did not trust ran on an affected host with the affected configuration.

Prevention

  • The sandbox vendor is in your threat model; a microVM boundary is only as good as the VMM's handling of its own error paths. See agent sandboxing.
  • Read the release notes of your isolation layer for behaviour changes, not for the word "security". This fix was a bugfix line for eight weeks.
  • Keep the jailer, seccomp and network namespaces on; the researcher's FC-03 chain shows what code inside the VMM can still do, and the jailer's chroot and namespaces bounded it.

Sources