Firecracker VM escape fixed; seccomp bypass still unfixed
Coinspect researchers demonstrated a chain that escapes a Firecracker microVM from root guest userspace (CVE-2026-122192), gaining code execution in the host-side monitor process, followed by a seccomp policy bypass (FC-03). The guest-to-Firecracker escape is fixed in v1.16.2 and v1.17.0; the FC-03 seccomp redesign is under review in PR #6287 and AWS does not plan a separate CVE. Operators of self-managed Firecracker should upgrade; AWS states its services, including Lambda, are not affected.
What happened
Security researchers at Coinspect publicly demonstrated an attack that breaks out of a Firecracker sandbox virtual machine into the host server, running code inside the Firecracker process and then performing host operations its security policy blocked. The main flaw is fixed in versions 1.16.2 and 1.17.0. AWS states its services, including Lambda, are not affected.
Why it matters
Firecracker runs untrusted workloads at cloud scale: it powers AWS Lambda and Fargate and also isolates AI agents in services such as Amazon Bedrock AgentCore, DigitalOcean Managed Agents, Vercel Sandbox and E2B. For companies running multi-tenant workloads on their own Firecracker, the flaw breaks guest-to-host isolation and puts the underlying server at risk. AWS reported in 2026 that Firecracker supports more than 15 trillion Lambda invocations per month.
What to do
Upgrade self-managed Firecracker to version 1.16.2 or 1.17.0 and follow the GitHub security advisory and the AWS security bulletin. Track PR #6287, which proposes the fix for the second flaw; AWS does not plan a separate CVE. Review the jailer setup: in the researchers' test, the attack's network stage failed under a dedicated network namespace (--netns).
For the technical team
- CVE
- CVE-2026-122192
- Affected
- AWS Firecracker (monitor de máquinas virtuais) · Firecracker before v1.16.2 and v1.17.0, running a snapshot-restored VM with the File memory backend and a balloon (PoC used a Full snapshot and virtio-balloon) or virtio-mem device.
- Exploitation
- Public proof of concept demonstrated by Coinspect (Juan Pablo Martinez Kuhn), blog last updated November 4, 2026 and shared on r/netsec. No in-the-wild exploitation reported in the sources.
- Fix
- CVE-2026-122192 fixed in Firecracker v1.16.2 and v1.17.0. FC-03 (seccomp bypass) has no final fix: the proposed seccomp redesign is under review in PR #6287; AWS does not plan a separate CVE. Official guidance in the GitHub security advisory and the AWS security bulletin. Partial mitigation observed: with a dedicated network namespace (jailer --netns), the network connection returned ENETUNREACH.
- Vector
- Firecracker memory-discard path with the File memory backend on a snapshot-restored VM plus a balloon or virtio-mem device. Memory corruption: the code tries to replace the snapshot-backed mapping with anonymous memory via mmap MAP_FIXED; if mmap fails after the old mapping is removed, the KVM memory slot stays active and an address the monitor (VMM) reuses becomes guest-accessible, letting the guest read and alter live VMM memory. Conditions: root in guest userspace with no guest-kernel code; guest-generated memory pressure consumes the per-microVM limit headroom and triggers the late failure. Second stage (FC-03): the VMM seccomp policy allowed io_uring_setup, io_uring_register and io_uring_enter; code already running in the VMM creates a fresh ring and performs host operations the policy blocked, such as a network socket to the host loopback.
- More details
- Two-stage chain: FC-05 (CVE-2026-122192) yields controlled code execution in the VMM's EventManager; FC-03 uses io_uring for host operations seccomp blocked; a direct socket call from the same VMM context was terminated with SIGSYS. Restrictions on an existing io_uring ring are not inherited by a new ring. The PoC ran with the default Sync block engine and no Firecracker-created ring in use. The balloon handler marked the request used before the discard and only logged the error on failure. AWS states its services, including Lambda, are not affected and customers need take no action. Firecracker's GitHub security-advisory page listed two published advisories as of October 21, 2026. Coinspect examined Firecracker only and did not assess the named services' deployments.
Timeline
Incident opened.
