HighVulnerabilityPatch available

Firecracker CVE-2026-122192: Coinspect discloses guest-to-VMM memory escape

Firecracker’s advisory says v0.23.0 to v1.16.1 let a guest root user access VMM memory after a failed discard; upgrade to v1.16.2 or v1.17.0.

Published
Fixed in
Firecracker v1.16.2, v1.17.0
Exploitation
No, the sources describe only a researcher proof of concept by Coinspect and report no in-the-wild exploitation

Live scores

CVE-2026-122192
EPSS
0.002
low predicted chance of attack
VEDAS
0.047
little exploit evidence
On CISA KEV
Not listed
Detection rule
No public rule yet

Live scores

CVE-2026-43366
EPSS
0.001
low predicted chance of attack
VEDAS
0.428
little exploit evidence
On CISA KEV
Not listed
Detection rule
No public rule yet

What happened

Security firm Coinspect says it demonstrated an escape from a Firecracker guest’s userspace into the host-side Firecracker process (the VMM), tracked as CVE-2026-122192 (Coinspect). The Firecracker project’s official GitHub advisory, GHSA-48ww-rqpp-2mgm, rates the issue High (CVSS 7.5). It says that in v0.23.0 through v1.16.1, “under certain host memory conditions”, a root user in a guest can read or modify memory of the Firecracker process after a failed guest memory discard (GitHub, firecracker-microvm).

According to the advisory, a failed memory discard can leave part of the guest memory range unmapped while Firecracker keeps running. Memory that Firecracker later allocates at that address can then become readable or writable from the guest (GitHub). Coinspect’s account of the cause:

  • Firecracker replaced snapshot-backed pages with anonymous memory using MAP_FIXED.
  • The balloon handler marked the discard request as used before attempting the discard, then only logged an error if the discard failed.
  • When the replacement failed after the old mapping was removed, the KVM memory slot stayed active, so the guest kept access to that host address.
  • Coinspect says its proof of concept caused the failure through guest-generated memory pressure against a per-microVM memory limit, and gained controlled code execution in the VMM (Coinspect).

Coinspect also reports a second, separate weakness it calls FC-03. The VMM seccomp policy allowed io_uring setup calls, so code already running in the VMM could create a fresh io_uring ring and perform host operations that direct system calls were blocked from, such as opening a network socket to a host loopback listener. According to Coinspect, AWS classifies FC-03 as a defense-in-depth improvement, does not plan to assign it a CVE, and a seccomp redesign is under review in PR #6287 (Coinspect).

Coinspect says one chained proof of concept panicked a host running a kernel vulnerable to a separate Linux flaw, CVE-2026-43366. It says it did not attempt host-kernel code execution (Coinspect).

According to Coinspect, the AWS security bulletin states that AWS services, including AWS Lambda, are not affected and that customers of those services need take no action. Coinspect says it did not assess deployments of other services that use Firecracker (Coinspect). In-the-wild exploitation is not confirmed by any source.

Am I affected?

According to the official advisory (GitHub), you are affected only if all of these apply:

  • You run Firecracker v0.23.0 through v1.16.1, inclusive. Within currently supported release lines, that means v1.16.0 and v1.16.1.
  • You restore a VM from a snapshot using the File memory backend.
  • That VM has a balloon or virtio-mem device.

You are not affected if:

  • Your VMs are started without a snapshot.
  • Your VMs are restored using the Uffd memory backend.

If you only use AWS services such as Lambda, AWS says no action is needed, according to Coinspect (Coinspect).

What to do now

  1. Upgrade Firecracker to v1.16.2, v1.17.0 or later. The advisory says the fix keeps the original mapping’s MAP_NORESERVE flag and terminates the process and its VM if the replacement mapping fails (GitHub).
  2. If you maintain a fork or derivative code, incorporate the fixes from PR #6174 and its v1.16 backport PR #6178 (GitHub).
  3. If you cannot upgrade immediately, restore snapshots using the Uffd memory backend. Follow its documented requirements for handling discarded pages (GitHub).
  4. As interim host settings, the advisory says to do the following. It notes these settings reduce but do not fully address the issue (GitHub):
    • Use heuristic memory overcommit (vm.overcommit_memory=0) rather than strict overcommit.
    • 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.
  5. Track PR #6287 for the FC-03 seccomp change. No CVE or separate advisory is planned for it, according to Coinspect (Coinspect).

Sources