Firecracker's First Real Escape: CVE-2026-122192, the FC-03 Seccomp Bypass, and What It Means for AI Agent Sandboxing

Updated

codex-clisecuritysandboxfirecrackermicrovmcvee2bvercelfly-iodefence-in-depth

Firecracker’s First Real Escape: CVE-2026-122192, the FC-03 Seccomp Bypass, and What It Means for AI Agent Sandboxing

CVE-2026-122192 is the first fully demonstrated guest-to-host escape chain from Firecracker’s own VMM code. The hypervisor that powers AWS Lambda, E2B, Fly Machines, Vercel Sandbox, and Amazon Bedrock AgentCore had, until 2026, avoided confirmed guest-to-host escapes. That changed in April 2026 when CVE-2026-5747 introduced the first escape-class vulnerability in Firecracker itself — an out-of-bounds write in the virtio-PCI transport that could potentially allow host code execution, though no complete exploit chain was publicly demonstrated at the time. CVE-2026-122192, publicly disclosed on 4 November 2026, goes further: a logic error in the balloon device’s memory-discard path that allows a guest-root attacker to reach and modify live Firecracker VMM address space, combined with a seccomp bypass that turns VMM access into full host-process code execution.

For Codex CLI users, the question is not abstract. If your team routes execution to E2B, Vercel Sandbox, or any Firecracker-backed platform for remote or cloud-based agent runs, the assumption that the sandbox fully contains agent-generated code was wrong for Firecracker versions 0.23.0 through 1.16.1 when those VMs were restored from a snapshot using the File memory backend with a balloon or virtio-mem device — a pattern widely used for fast-boot production deployments.1

What Firecracker Is and Why It Became the Default

Firecracker is an open-source Virtual Machine Monitor (VMM) built by Amazon and released in 2018. It runs microVMs — lightweight virtual machines with dedicated Linux kernels — in milliseconds, with memory footprints small enough to run thousands of instances per host. The core security proposition is simple: each microVM has its own kernel. A guest process cannot reach the host kernel through shared-namespace tricks or container-escape techniques, because there is no shared namespace. The guest kernel and host kernel are separated by a hypervisor boundary enforced by KVM.

This made Firecracker the natural choice for AI agent execution platforms. When a Codex CLI session delegates work to an E2B sandbox, or when Vercel runs agent-generated code inside its Sandbox product, that code runs in a Firecracker microVM. The isolation guarantee is the entire point: an agent that generates malicious or erroneous code cannot escape the microVM and touch the host.

CVE-2026-122192 breaks that guarantee under specific but achievable conditions.

The Vulnerability: A Two-Stage Escape

The root cause is a logic error in the error-handling path of Firecracker’s balloon device — the memory management component that allows the host to reclaim guest memory by inflating a “balloon” that absorbs guest RAM pages.2 The GitHub security advisory explicitly notes this is not a race condition; it is a failure to maintain memory-mapping invariants when a discard operation fails.

Stage One: CVE-2026-122192 — KVM Slot Confusion

When Firecracker inflates the balloon, it replaces guest-RAM mappings with anonymous pages using MAP_FIXED. The implementation marks the balloon request as completed before attempting the memory replacement. If memory pressure causes the replacement to fail after the original mapping has already been removed — that is, after the old mapping is gone but before the new anonymous pages are established — the result is a still-active KVM slot that now points into Firecracker’s own process address space rather than guest memory.

A guest process with root privileges can trigger this condition deliberately by generating sustained memory pressure that pushes consumption against the per-microVM memory limit. Once that mapping failure is induced, the guest can read and write Firecracker’s VMM memory directly. With controlled writes into the event loop, arbitrary code execution on the host-side process follows.2

Stage Two: FC-03 — Seccomp Policy Bypass

Firecracker applies a seccomp filter to its own process, restricting which system calls the VMM can make. This is a defence-in-depth measure intended to limit what a compromised VMM can do on the host. The researchers found that the EventManager — the VMM’s event loop — retains permission to use io_uring system calls, which are broad enough to perform host operations that the seccomp policy is intended to block.2

The two-stage chain: trigger the KVM slot confusion to gain execution in the EventManager, then use the permitted io_uring calls to bypass the seccomp restrictions and reach the host OS.

The result is full guest-to-host escape from unprivileged guest userspace, achievable by any process running inside the microVM with root privileges — a condition that is standard for AI coding agents, which typically run as root inside their sandboxes.

Affected Platforms and Versions

Firecracker versions 0.23.0 through 1.16.1 are vulnerable, subject to a critical scope caveat: exploitation requires VMs restored from a snapshot using the File memory backend with a balloon or virtio-mem device. VMs started without a snapshot, or restored using the Uffd memory backend, are not affected. This covers a large share of production Firecracker deployments that rely on snapshot-based fast boot, but it is not every Firecracker deployment.

The fix ships in v1.16.2 and v1.17.0. The patch retains the original mapping’s MAP_NORESERVE flag when replacing discarded memory, and terminates the Firecracker process rather than allowing execution to continue with an invalid guest memory mapping.1

Platforms that have publicly confirmed Firecracker exposure:

Platform Status as of 11 Nov 2026
Fly.io Machines Mitigations deployed fleet-wide 5 Nov; rolling Machine restarts in progress; fly deploy to accelerate3
E2B Uses Firecracker; no public statement as of this writing
Vercel Sandbox Separate KVM zero-day disclosed Oct 2026 (no CVE); CVE-2026-122192 exposure not yet confirmed publicly
Amazon Bedrock AgentCore AWS confirmed Firecracker use; no public statement on CVE-2026-122192
DigitalOcean Managed Agents No public statement

Fly.io’s response is the most transparent: fleet-wide mitigations were deployed on 5 November 2026, within one day of the 4 November AWS disclosure, with staggered Machine restarts to avoid simultaneous downtime across multi-Machine deployments.3

Which Codex CLI Execution Patterns Are Affected

Codex CLI’s native OS-level sandbox — Seatbelt on macOS, Landlock on Linux — does not use Firecracker. If you are running Codex CLI locally with the standard sandbox enabled, CVE-2026-122192 does not apply to your setup. The native sandbox has a different attack surface and was not part of the July 2026 comparative study that rated it favourably for host kernel protection.4

The affected pattern is remote or cloud delegation:

  • E2B tool use in Codex CLI — if you have configured the E2B MCP server or the --sandbox e2b flag to route code execution to E2B cloud sandboxes, your execution environment was running vulnerable Firecracker versions.
  • Vercel Sandbox integration — teams using Vercel’s AI SDK sandbox mode for Codex CLI-generated code have exposure to both the KVM zero-day disclosed in October and potentially CVE-2026-122192.
  • Fly.io-hosted Codex deployments — teams running Codex CLI agents inside Fly Machines (a common pattern for persistent multi-agent deployments) were exposed; Fly.io’s mitigations reduce but may not eliminate risk until Machine restarts complete.
  • Custom Firecracker deployments — if your team runs a self-hosted Firecracker fleet for agent isolation, check your version immediately.

The Codex CLI Cloud backend, which runs on OpenAI infrastructure, has not disclosed which hypervisor technology it uses. OpenAI has not commented on CVE-2026-122192 in relation to Codex Cloud threads.

Immediate Mitigations

If you manage a Firecracker deployment: Upgrade to v1.16.2 or v1.17.0. The patch is a targeted fix to the balloon device’s memory-replacement ordering — the mapping is now preserved until the anonymous page establishment succeeds, and Firecracker halts rather than leaving an inconsistent KVM slot.1

If you use E2B: Pin your SDK usage to the most recent E2B runtime release and monitor E2B’s security advisories for a statement on their Firecracker version. Consider temporarily routing sensitive agent sessions to local execution with native Codex CLI sandboxing until E2B confirms they are running patched versions.

If you use Vercel Sandbox: The October KVM zero-day is a separate disclosure without a published patch or CVE assignment as of late October 2026. Monitor Vercel’s security blog. For high-sensitivity workloads, local execution with Codex CLI’s native Landlock/Seatbelt sandbox provides better-understood isolation guarantees.

If you use Fly.io Machines for agent hosting: Run fly deploy on your Codex agent applications to trigger a fresh Machine restart with the mitigated Firecracker version.

What This Changes About Sandbox Assumptions

The more important lesson from CVE-2026-122192 is not the specific vulnerability — that will be patched and forgotten — but what it reveals about the security model for AI agent execution platforms.

The marketing claim that microVM sandboxes provide “hypervisor-grade isolation” is technically accurate but practically misleading. Hypervisor-grade isolation means the isolation is as strong as the hypervisor implementation. Hypervisors have CVEs. Firecracker, specifically, had a theoretical zero-CVE record that the community cited as evidence of exceptional security discipline. That record is now gone.

This does not mean microVM sandboxes are insecure. Firecracker’s isolation is still dramatically stronger than container-only approaches, and the patched versions restore the intended guarantee. But it does mean that defence-in-depth — the layering of multiple independent isolation mechanisms — is not optional for production AI agent deployments.

For Codex CLI configurations in particular, this suggests:

  1. Prefer local native sandboxing for sensitive workloads. Codex CLI’s Landlock (Linux) and Seatbelt (macOS) provide OS-kernel-enforced constraints that do not depend on a third-party hypervisor. They have a narrower attack surface precisely because they make fewer infrastructure promises.
  2. Treat third-party sandboxing platforms as dependent on their patch cadence. When you route execution to E2B, Vercel, or Fly.io, you inherit their security posture and their vulnerability timeline. Build your threat model accordingly.
  3. Monitor AGENTS.md model selection policies against execution environment. If your AGENTS.md routes high-trust agentic tasks to a cloud sandbox backend, consider whether that backend’s isolation guarantees have changed since you wrote the policy.

The assumption that “code runs safely because the box is Firecracker” was always a trust relationship with AWS’s implementation quality. CVE-2026-122192 is a concrete data point in calibrating that trust.

Summary

Item Detail
CVE CVE-2026-122192 (+ FC-03 seccomp bypass)
Disclosed 4 November 2026 (AWS bulletin 2026-169-AWS)
Root cause Logic error in balloon device memory-discard path; KVM slot not invalidated on MAP_FIXED replacement failure (not a race condition)
Affected versions Firecracker 0.23.0 – 1.16.1
Patched versions v1.16.2, v1.17.0
Platforms confirmed affected Fly.io Machines; E2B, Vercel Sandbox, Bedrock AgentCore (Firecracker users, unconfirmed patch status)
Codex CLI native sandbox Not affected (Landlock/Seatbelt, not Firecracker)
Immediate action Upgrade Firecracker; fly deploy on Fly-hosted agents; monitor E2B/Vercel advisories

  1. Coinspect Security Research, “Escaping Firecracker from Guest Userspace,” November 2026. https://www.coinspect.com/blog/firecracker-escape/ — AWS security bulletin 2026-169-AWS: https://aws.amazon.com/security/security-bulletins/2026-169-aws/ — GitHub advisory GHSA-48ww-rqpp-2mgm: https://github.com/firecracker-microvm/firecracker/security/advisories/GHSA-48ww-rqpp-2mgm ↩ ↩2 ↩3

  2. CVE-2026-122192 technical analysis. Root cause: logic error in MAP_FIXED memory replacement ordering in balloon device error-handling path (not a race condition per GHSA-48ww-rqpp-2mgm). Two-stage exploit: KVM slot confusion → EventManager code execution → io_uring seccomp bypass (FC-03). ↩ ↩2 ↩3

  3. Fly.io community, “CVE-2026-122192 (Firecracker escape) update,” 5–7 November 2026. https://community.fly.io/t/cve-2026-122192-firecracker-escape-update/29004 ↩ ↩2

  4. Andronchik and Lokhmakov comparative sandbox security study, cited in “AI Code Sandbox Security Showdown,” July 2026. articles/2026-07-07-ai-code-sandbox-comparative-security-codex-cli-landlock-seatbelt-engine-class-isolation-architecture.md ↩