Home - Coinspect Security
A luminous compute core inside a glass isolation cube, with light crossing a breach in its boundary

Escaping Firecracker from Guest Userspace

Juan Pablo Martinez Kuhn
linkedin icon twitter icon
Director of Security Services
Sandbox Escape, Agentic Systems

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. We read and changed live Firecracker memory and gained controlled code execution in the Firecracker process on the host. A separate flaw we reported let the compromised process bypass another containment layer and perform host operations that Firecracker’s policy explicitly forbids.

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.

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 these services’ deployments.

Firecracker’s public advisory record is sparse: its GitHub security-advisory page listed two published advisories as of October 21, 2026. A demonstrated failure of its core guest isolation stands out against that record.

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.

How the Exploit Chain Works

Our exploit chain combines two independent issues:

  • FC-05 lets the guest cross into the host-side Firecracker process, the virtual-machine monitor (VMM). A fix is available.
  • FC-03 requires code already running in the VMM, whether it got there through FC-05 or another route. It bypasses restrictions on the host operations available to that code.

AWS is addressing FC-03 through a redesign, so we are withholding its mechanism until the fix and advisory are public.

Figure 1 traces the exploit chain across two security boundaries.

The guest requests memory discards for snapshot-backed RAM. FC-05 gives the guest read and write access to live Firecracker memory, which the researchers used to gain code execution in the VMM. FC-03 then lets that VMM code perform host operations blocked by Firecracker's policy.

Figure 1. FC-05 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.

How FC-05 Crossed the Boundary

FC-05 affects how Firecracker discards guest RAM after restoring a Full snapshot. In the affected setup, that RAM is privately mapped from the snapshot’s RAM file. Our proof of concept reached the affected function through a traditional virtio-balloon device, which lets the guest request that Firecracker reclaim selected pages. The same function serves other memory-discard paths.

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 records the guest request as used, logs the error and continues.

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 guest 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 associates a guest-memory range with a host address. Firecracker must not reuse that host address for its own data while the slot still directs guest access there. After the late failure, the slot remains active even though the original guest-RAM mapping is gone. KVM records the address range, not who owns the memory later placed there.

A legitimate Firecracker allocation can then reuse the address. The still-active slot resolves guest access to that allocation, allowing the guest to read and change live VMM-owned memory. FC-05 is therefore a Firecracker memory-ownership defect; exploiting a separate Linux or KVM vulnerability is unnecessary for this first boundary crossing.

Before the failure, a KVM slot directs guest access to guest RAM. The guest-RAM mapping is then removed, the replacement fails, and Firecracker later reuses the same host address. Because the slot remains active, the guest can read and change Firecracker&#x27;s new allocation.

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

We used FC-05’s memory read/write access to gain execution in Firecracker’s EventManager, its main event loop for VMM and device work. That gave us the VMM execution required to exploit FC-03.

What We Demonstrated

Figure 3 compares what the two proofs of concept demonstrated, with their common guest-to-VMM steps aligned.

Both proofs of concept used the same guest memory-discard and FC-05 VMM-access stages. In the guest-userspace proof of concept, a normally blocked host action succeeded and a host test listener got our message over the network. In the guest-kernel proof of concept, a vulnerable host-kernel path was reached and a disposable host panicked. Host-kernel code execution was not attempted but remains possible.

Figure 3. Two proofs of concept using FC-05 and FC-03, with different observed outcomes.

The guest-userspace proof of concept gained controlled execution in Firecracker, then used a network operation forbidden by Firecracker’s host policy to send a message to our listener on the test host. Receiving that message confirmed the second boundary crossing.

In the guest-kernel proof of concept, FC-05 alone crossed the guest-to-Firecracker boundary; FC-03 then let the VMM reach a host-kernel interface unavailable directly to the guest. We chose CVE-2026-43366 as an observable example of that access: triggering it caused a host panic. The flaw can corrupt kernel memory and may provide a route to host-kernel code execution, which we did not attempt.

Fix Status

Firecracker PR #6174 repairs the FC-05 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. AWS confirmed that the repair shipped in the patched releases v1.16.2 and v1.17.0.

Coinspect independently found FC-05 before Firecracker merged PR #6174. The PR fixed the memory-discard bug but did not describe the guest-to-VMM security impact we demonstrated. AWS later confirmed FC-05 as a security issue.

The full vendor-confirmed affected range, additional backports, and official advisory guidance remain pending.

The separate FC-03 redesign is still in progress.

Disclosure Timeline

  • August 25, 2026: Coinspect preserved the first source and runtime evidence of the private-snapshot memory-protection failure that led to FC-05.
  • 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, before our submission.
  • September 2–4: We submitted the FC-05 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 FC-05 repair.
  • September 17–27: We reproduced FC-05 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 FC-05 entry with FC-03, sent a network message to a listener on the test host, and recorded Firecracker exiting normally.
  • October 2026: AWS confirmed privately that FC-05 is a guest-to-VMM security issue, that our validation supported the repair, and that the guest-userspace prerequisite would be considered in severity scoring. AWS began preparing an FC-05 CVE, GHSA and bulletin.

Further Technical Analysis

Coinspect will publish FC-03’s mechanism and further research details after the fix and advisory are public.