- Firecracker's advisory says versions v0.23.0 through v1.16.1 could let a root guest reach the Firecracker process's memory, but only in one snapshot-restore setup.
- The flaw shows that a sandbox is judged by what it does when a step fails. The fix ends the VM instead of continuing.
- Check your Firecracker version and restore method. Upgrade to v1.16.2 or v1.17.0, or ask your provider whether it is affected.
A sandbox earns trust by how it behaves when something breaks. A recent Firecracker flaw is a clear case. A memory step failed. The program wrote a line in its log and kept going. This applied only to VMs restored from snapshots in one particular setup.
AWS-backed Firecracker is open source software that starts small, isolated virtual machines. Lambda runs on it, along with other serverless services. The project's advisory, GHSA-48ww-rqpp-2mgm, thanks Juan Pablo Martinez Kuhn of Coinspect. He worked with the project through coordinated disclosure.
What the advisory says
The affected releases run from v0.23.0 to v1.16.1, the project reports. The risk is a guest user with root rights reaching the memory of the Firecracker process itself. It can happen when the host is short on memory and a request to free guest memory fails.
Two conditions must both hold. First, the VM came back from a snapshot, with its memory loaded from a file (the File backend). Second, it has a balloon or virtio-mem device, which lets the guest hand memory back to the host.
VMs started fresh are not affected. Nor are VMs restored with the Uffd backend. Patched builds are v1.16.2 and v1.17.0.
How the failure works
Each workload runs in a microVM. That is a small virtual machine, called the guest. A host-side program called the virtual-machine monitor manages it.
To free snapshot-backed pages, old versions swap the memory mapping for fresh, blank memory at the same address. Coinspect explains that the old mapping can go before the new one is in place. Trouble starts if the swap fails in between.
Coinspect found that the balloon code marked the guest's request as done before it tried the discard. When the discard failed, the code logged an error and moved on.
The advisory describes the result. A piece of the guest's memory range stays unmapped. Firecracker keeps running. Memory it allocates there later can be read or changed by the guest's root user.
Coinspect's demonstration used memory pressure created inside the guest. That pressure used up the room left under a per-microVM memory limit. Coinspect says such limits match Firecracker's production guidance.
The demonstration needed root in the guest. It did not need any code running in the guest's kernel.
The fix has two parts. The replacement memory now keeps the original's reservation setting, a flag called MAP_NORESERVE that tells the host not to set aside backing memory in advance. If the swap still fails, Firecracker ends the process and its VM.
What this does not show
Coinspect relays AWS's security bulletin. It says AWS services, Lambda included, are unaffected. AWS tells customers of those services to do nothing.
Coinspect also names four AI agent platforms that use Firecracker to isolate code: Amazon Bedrock AgentCore, DigitalOcean Managed Agents, Vercel Sandbox and E2B. Coinspect studied Firecracker itself. It did not assess how those services deploy it. This report draws no conclusion about them either.
Coinspect's chain had a second stage, called FC-03. It concerns a proposed seccomp redesign under review in PR #6287. Coinspect reports that AWS has no plan to issue a CVE just for that stage.
The lesson: stop instead of carrying on
The core change is small. Firecracker used to treat a failed discard as something to note. Now it treats it as a reason to stop the VM.
Think of a fuse. When it trips, you lose one circuit. A wire that keeps carrying current through a fault can cost far more. Ending one microVM loses one workload. Carrying on with a broken memory map put the boundary itself in doubt.
This matters more as software agents run code for a company. Coinspect argues that agents able to run code raise the stakes for isolation. Vercel names its Firecracker microVM as the security boundary for its sandbox's compute.
Coinspect also saw two published advisories on Firecracker's GitHub page on October 21, 2026. That is a short list for a platform used at this scale. One data point is not a trend. The useful lesson is the design choice, not the count.
What to ask your team
Start with exposure. Do we run Firecracker directly, or through a provider? If directly, which version do we run? Do we restore snapshots with the File memory backend and a balloon or virtio-mem device? Teams that maintain forks should add the matching fixes.
If you cannot upgrade yet, the project suggests restoring snapshots with the Uffd backend. It also lists host settings. Choose the looser, default-style memory overcommit mode (vm.overcommit_memory=0) over the strict one. Size each VM's guest memory, virtio-mem region included, at no more than the host's RAM plus swap. Leave the out-of-memory killer switched on for Firecracker's memory cgroup. The project says these settings reduce the risk but do not fully address it.
Then put a wider question to every sandbox vendor. When a step inside your isolation layer fails, does it stop or carry on? A boundary should fail closed: stop, not continue.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Firecracker project (firecracker-microvm, AWS-maintained open source); advisory GHSA-48ww-rqpp-2mgm.
