Escaping Firecracker from Guest Userspace

Firecracker runs untrusted workloads in lightweight virtual machines at cloud scale. Each such machine, or microVM, is a guest: a sandbox meant to keep its programs separate from the host, the underlying server running Firecracker.

Coinspect demonstrated a Firecracker sandbox escape from guest userspace. Our exploit chain had two stages:

• FC-05 — guest-to-Firecracker escape: We read and changed live Firecracker memory and gained controlled code execution in its host-side process (CVE-2026-122192).
• FC-03 — seccomp policy bypass: With code running in Firecracker, we then demonstrated a second, independent weakness that let us perform host operations its seccomp policy otherwise blocked.

The guest-to-Firecracker issue is fixed in Firecracker v1.16.2 and v1.17.0. The GitHub security advisory and AWS security bulletin provide the official guidance. FC-03’s proposed seccomp redesign is under review in PR #6287; AWS does not plan to assign it a separate CVE. See Fix Status for affected versions and repair.

Why Firecracker Matters

Firecracker is one of the leading security-focused sandbox platforms. Its design combines hardware virtualization, a deliberately small guest-facing attack surface, and multiple layers of containment. It powers AWS Lambda and Fargate; AWS reported in 2026 that Firecracker supports more than 15 trillion Lambda invocations per month.

AWS states in its security bulletin that its services, including AWS Lambda, are not affected by this issue and that customers of those services need take no action.

Firecracker has had a short public advisory record for a platform used at this scale: its GitHub security-advisory page listed two published advisories as of October 21, 2026.

Firecracker is also used to run or isolate AI agents and their code in Amazon Bedrock AgentCore, DigitalOcean Managed Agents, Vercel Sandbox and E2B. Vercel identifies its Firecracker microVM as the sandbox’s compute security boundary. As agents gain the ability to execute code, the strength of this isolation becomes more consequential. Our research examined Firecracker itself; we did not assess the named services’ deployments.

How the Exploit Chain Works

The boundary we tested is fundamental to Firecracker: root inside a guest is still supposed to stay inside that guest. Firecracker assumes even the guest kernel may be malicious. Our guest-userspace proof of concept required root privileges but no code running in the guest kernel.

The affected setup involves a VM restored from a snapshot using the File memory backend, plus a balloon or virtio-mem device that lets the guest request memory discard. The File backend privately maps the snapshot’s RAM file into the Firecracker process.

Firecracker’s host-side process is the virtual-machine monitor (VMM). Figure 1 shows how the guest reached the VMM and how code running there then reached host operations blocked by Firecracker’s policy.

Figure 1. The guest-to-Firecracker escape gives the guest access to live VMM memory and a path to code execution; FC-03 lets that code perform host operations Firecracker’s policy blocks.

CVE-2026-122192: Escaping the Sandbox

Our proof of concept used a Full snapshot and the traditional virtio-balloon device to reach Firecracker’s memory-discard path.

To discard snapshot-backed pages, affected Firecracker versions try to replace their host mapping with anonymous memory—new pages no longer backed by the snapshot file—at the same address. This uses MAP_FIXED: the old mapping can be removed before the new one is installed. The dangerous case is a failure after that removal; a failure that leaves the old mapping intact does not create this ownership problem. The balloon handler marks the guest’s balloon discard request as used before attempting the discard; if the discard fails, it logs the error and continues.

In our proof of concept, guest-generated memory pressure consumed the headroom allowed by a preconfigured per-microVM memory limit—a resource control consistent with Firecracker’s production guidance—and caused that late failure.

The affected memory-discard code attempted the replacement below (failure path shown):

let ret = unsafe {
    libc::mmap(
        phys_address.cast(),
        len,
        libc::PROT_READ | libc::PROT_WRITE,
        libc::MAP_FIXED | libc::MAP_ANONYMOUS | libc::MAP_PRIVATE,
        -1,
        0,
    )
};
if ret == libc::MAP_FAILED {
    let os_error = std::io::Error::last_os_error();
    error!("discard_range: mmap failed: {:?}", os_error);
    Err(GuestMemoryError::IOError(os_error))
}

The balloon handler marked the balloon discard request as used before calling discard_range and logged the error if it failed:

queue.add_used(head.index, 0)?;
// ... prepare the page ranges ...
if let Err(err) = mem.discard_range(
    guest_addr,
    usize::try_from(range_len).unwrap() << VIRTIO_BALLOON_PFN_SHIFT,
) {
    error!("Error removing memory range: {:?}", err);
}

From Failed Replacement to VMM Access

KVM, the host’s virtualization component, keeps a memory slot that links a guest-memory range to a host address. The late failure removed the guest-RAM mapping but left this slot active: KVM still treated the address as guest memory. When Firecracker later reused that address for its own data, the guest could read and change the live VMM allocation. KVM tracked the address, not its new owner.

Figure 2. The still-active KVM slot directs guest access to Firecracker memory after the failed replacement and address reuse.

FC-03: Firecracker Seccomp Policy Bypass

FC-03 requires code already executing in a VMM thread, whether through the guest-to-Firecracker escape or another route. In our chain, the escape supplied that execution in Firecracker’s EventManager, the VMM’s main event loop for device work. FC-03 let that code use the host’s io_uring interface, which submits operations to the host kernel through shared queues.

Firecracker uses seccomp to filter the system calls its VMM threads make to the host kernel. The affected VMM seccomp policy nevertheless allowed the io_uring setup, registration and submission system calls:

[
  { "syscall": "io_uring_setup" },
  { "syscall": "io_uring_register" },
  { "syscall": "io_uring_enter" }
]

When Firecracker creates an io_uring ring for asynchronous I/O, it starts the ring disabled, registers the permitted operations and file descriptors, then enables it. Those restrictions apply to that specific ring; a new ring does not inherit them. The Firecracker ring setup code shows this sequence.

Our proof ran with Firecracker’s default Sync block engine, and no Firecracker-created ring was in use. In the affected filter, io_uring_setup was still allowed in this configuration. Our exploit code ran in the EventManager, created a fresh ring with io_uring_setup, then requested a network socket, connected to a listener on the host’s loopback interface, and sent a message. A direct socket call from the same VMM context was terminated by the seccomp filter with SIGSYS; the ring-based request reached the listener.

The successful host-listener run used the jailer without --netns. In a check with a dedicated network namespace, the same operation returned ENETUNREACH.

The jailer documentation lists --netns as optional and says the jailer joins a specified network namespace only when the flag is supplied; it is not enabled by default. Firecracker’s production host setup guide recommends the jailer or equivalent constraints but does not recommend --netns as a default. Its snapshot networking guide also shows that a namespace can have network connectivity. The ENETUNREACH result therefore describes our tested namespace, not every --netns deployment.

Separate checks showed that a fresh ring could also modify the filesystem in ways blocked for Firecracker’s direct system calls. The requests still ran with the Firecracker process’s credentials and within the jailer’s chroot and namespaces.

The seccomp redesign proposed in PR #6287 would remove io_uring_setup from the default Sync configuration we tested, blocking our fresh-ring route to the vulnerable host-kernel interface. It would also keep io_uring blocked by default for PCI microVMs that support drive hotplugging. An Async drive configured at boot or an explicit Async I/O opt-in would retain the necessary rules; the new hotplug_async_drives option is off by default. AWS describes Async I/O as a developer-preview feature not intended for production use.

What We Demonstrated

Both proofs of concept followed the same guest-to-Firecracker escape → FC-03 sequence: the escape supplied execution in the VMM, and FC-03 made host operations available that Firecracker’s direct system-call policy blocked. Figure 3 shows the different outcomes we demonstrated with that access, starting with the host-kernel result.

Figure 3. The same guest-to-Firecracker escape → FC-03 chain produced two outcomes; the host panic also depended on Linux CVE-2026-43366.

The guest-kernel proof of concept panicked a host running a kernel vulnerable to CVE-2026-43366, a separate Linux flaw. That flaw can corrupt kernel memory and may lead to host-kernel code execution, which we did not attempt. The guest-to-Firecracker escape supplied VMM execution and FC-03 made the host io_uring interface reachable; the guest could not reach that host interface directly. We submitted an IORING_OP_RECV and registered a provided-buffer ring through io_uring_register and IORING_REGISTER_PBUF_RING to reach the vulnerable buffer-recycling path.

The guest-userspace proof of concept sent a network message to our listener on the test host after reaching EventManager. We restored the modified VMM state, and Firecracker exited normally.

Fix Status

Firecracker PR #6174 repairs the vulnerable memory-replacement path. It preserves the intended mapping properties and stops Firecracker if a destructive replacement fails, rather than continuing after guest-memory ownership has become uncertain.

Firecracker v0.23.0 through v1.16.1 are affected. AWS confirmed that the repair shipped in v1.16.2 and v1.17.0. For the official record and guidance, see CVE-2026-122192, GHSA-48ww-rqpp-2mgm, and the AWS security bulletin.

AWS classifies FC-03 as a defense-in-depth improvement because it requires prior VMM compromise and does not plan to assign it a CVE or issue a separate advisory. The seccomp redesign remains under review in PR #6287.

Disclosure Timeline

• August 25, 2026: Coinspect preserved the first source and runtime evidence of the private-snapshot memory-protection failure behind the guest-to-Firecracker escape.
• August 27–28: Our guest-kernel proof of concept showed that the stale KVM memory slot gave the guest access to a Firecracker allocation and led to controlled execution in the VMM.
• September 1: Firecracker merged PR #6174, after Coinspect independently identified the guest-to-Firecracker flaw but before we reported it. The PR repaired the memory-discard bug but did not describe the guest-to-VMM security impact we demonstrated.
• September 2–4: We submitted the guest-to-Firecracker escape and FC-03 findings and the separate host-kernel reach demonstration privately to AWS.
• September 10: Firecracker published v1.16.2 and v1.17.0 with the guest-to-Firecracker repair.
• September 17–27: We reproduced the escape from guest userspace with root privileges and showed that the guest could read and change live Firecracker memory. We also confirmed that the patched release stopped the faulty memory behavior.
• October 1: We combined the guest-userspace escape with FC-03, sent a network message to a listener on the test host, and recorded Firecracker exiting normally.
• October 2026: AWS privately confirmed the guest-to-VMM escape as a security issue and acknowledged that our validation supported the repair. It began preparing the CVE, GHSA and bulletin.
• October 28: Our initial source review of the proposed FC-03 change in PR #6287 showed that it would block the fresh-ring route in the default Sync configuration we tested.
• November 4: AWS published CVE-2026-122192, GHSA-48ww-rqpp-2mgm, and its security bulletin.

Thanks Codex

Codex helped turn hypotheses into experiments: it wrote tests and instrumented Firecracker so we could observe its behavior. Human researchers reviewed the results and decided what to pursue next. When Codex dismissed a path as impossible, researchers revisited it and proposed ways to investigate it further. When repeated attempts stopped producing evidence, they redirected the work and opened new lines of investigation. Demonstrating this issue’s exploitability required extensive analysis and carefully instrumented experiments; we estimate that a researcher working without Codex would have needed roughly 20 times as long to reach comparable confidence. A future post will describe those turning points and how they shaped the research.

Wider access to the strongest models and sufficient tokens could make investigations of this depth possible for more security researchers.