Firecracker’s memory isolation fix matters on the restore path

A snapshot lets a platform bring back a virtual machine without booting it from scratch. It also gives the platform another way to put guest memory back in place. The November 4, 2026, Firecracker advisory for CVE-2026-122192 is about that second path. In a particular restore configuration, a failed memory operation can let someone with root access inside a microVM read or change memory belonging to the Firecracker process on the host. [1] [2]

AWS says its services, including Lambda, are unaffected and require no customer action for this issue. The people who need to check are those operating their own affected Firecracker installations or maintaining derivatives. Knowing that a managed service uses Firecracker is not the same as knowing it uses the vulnerable setup. [1]

The exposure depends on how the VM started

The issue requires a VM restored from a snapshot with the File memory backend and equipped with a balloon or virtio-mem device. Those devices let the guest and host adjust memory use. Under certain host memory conditions, a failed discard can leave part of the address range reserved for guest memory without a valid mapping. In affected releases, Firecracker can continue running. If the process later allocates its own memory in that range, a guest root user could read or write it. The advisory excludes fresh boots and restores that use the Uffd memory backend. [2] [5]

Consider a hypothetical build platform. It boots a clean runner, captures a snapshot once the tools are ready, and restores from that image for the day's jobs. If the platform lets jobs obtain root in the guest, it still expects the host process to be out of reach. A test of the original boot would miss the particular memory setup created by a restore. The platform's faster launch path deserves its own isolation checks, even if both paths end at the same shell prompt.

The patch and the snapshot travel together

The maintainers list v0.23.0 through v1.16.1 inclusive as affected when the configuration matches. They identify v1.16.0 and v1.16.1 as affected within the supported lines. The fix is in v1.16.2 and v1.17.0, both published on September 10, 2026. If a replacement memory mapping fails, patched Firecracker stops the process and its microVM rather than running with an invalid mapping. Operators with forks should check for the corresponding changes. [1] [2] [3] [4]

There is a practical wrinkle for the rollout: the v1.16.2 release notes say it cannot load snapshots made by v1.16.0 or v1.16.1, and those versions cannot load snapshots made by v1.16.2. A snapshot can be perfectly intact and still be unreadable to the binary you just installed. If the fleet uses those versions, plan to produce and test compatible snapshots along with the update. A rollback plan also needs to account for the vulnerable configuration it could bring back. [2] [3]

When an update cannot happen immediately, the maintainers describe Uffd restores as an alternative with requirements for handling discarded pages. Their documentation explains the page fault handler's responsibilities, including the need to return zeroed pages after a balloon discard instead of loading old data from the snapshot. It is a change to the restore path, with its own behavior to verify before relying on it. [2] [5]

The binary is only half the rollout if a scheduler can still select an older restore image. For the hypothetical build fleet, that means a spare host or a less frequently used runner class can quietly keep the old pairing in service. Treat the snapshot version and the software that loads it as a pair when you record what is deployed.

A restore test needs to run a real job

Our reading is that version, device configuration and snapshot provenance belong in the same operational record. For the example build platform, a successful restore should lead to a representative build, its expected result and a clean teardown. The team also needs to see whether a failed restore is surfaced clearly instead of leaving a job waiting for a runner that will never arrive.

The advisory does not establish that any individual host was exploited. It gives operators enough detail to ask a better question than whether Firecracker is present: which VMs take the affected path, and can the patched path do the work those VMs are there to do? [1] [2]