Firecracker's First Escape CVEs: What CVE-2026-5747 and CVE-2026-1386 Mean for MicroVM Sandboxes

For six years, Firecracker held a record no other sandbox substrate could claim: zero published hypervisor-escape CVEs. AWS Lambda and Fly.io run it at planetary scale, E2B and Vercel Sandbox built the AI-agent-sandbox category on it, and "it's a microVM, not a container" became the sentence that ended isolation arguments. In 2026, that record broke — twice, in two completely different parts of the codebase.

TL;DR — the verdict up front. CVE-2026-5747 (out-of-bounds write in the opt-in virtio-pci transport, CVSS 8.7 High) and CVE-2026-1386 (arbitrary host-file overwrite via symlink in the jailer's init copy, CVSS 6.0 Medium) are Firecracker's first escape-class CVEs in its own code rather than the KVM layer beneath it. Neither dethrones the microVM as the strongest practical sandbox default — but "it's a microVM" is no longer a settled argument, it's a maintenance contract. If you operate Firecracker anywhere, the versions that matter are:

Patched? Then the rest of this post is the why it matters — which trust layer each bug breached, and the checklist that turns two advisories into durable posture.

CVE-2026-5747: an out-of-bounds write in the virtio-pci transport​

The more serious of the two bugs lives in Firecracker's virtio PCI transport — the code that emulates PCI configuration space for guest virtio devices. A guest with root privileges could modify virtio queue configuration registers after device activation, and the VMM's common-config write path failed to validate the resulting queue size before using it as an index — an unchecked write into write_common_config_word in the PCI transport's common_config.rs that produces an out-of-bounds write in the VMM process itself.

The impact range is what makes this escape-class: at minimum, a malicious guest crashes the Firecracker VMM process (a host-side denial of service that kills every sandbox on that VMM instance). At maximum, it is potential arbitrary code execution on the host. AWS's bulletin is precise about the maximum requiring more: host code execution needs additional preconditions, "such as the use of a custom guest kernel or specific snapshot configurations."

No full guest-to-host RCE chain has been publicly demonstrated — but the primitive crosses the host boundary, which is exactly the line Firecracker's threat model exists to hold. ("All vCPU threads are considered to be running malicious code as soon as they have been started," per the design doc — this CVE is that assumption being tested for real.)

Three scoping facts keep the severity honest rather than hyped:

1. The PCI transport is opt-in. It requires the --enable-pci flag at VMM start. The default MMIO transport is unaffected, so fleets that never turned PCI on were never exposed. The tradeoff for opting out under pressure is real, though: AWS notes that switching from PCI back to MMIO "may result in reduced I/O throughput and increased latency" — PCI exists because MMIO costs performance.
2. The attacker needs guest root. This is not a drive-by from an unprivileged sandbox process; the exploit starts from a fully compromised guest. For single-tenant-per-microVM agent sandboxes (the E2B model), that means the tenant attacking its own sandbox's host — the exact threat multi-tenant sandbox fleets exist to contain.
3. No AWS service was affected, and the reporter is a name worth noting: Anthropic disclosed it through the AWS Vulnerability Disclosure Program. The lab training frontier models is now also auditing the sandbox substrate the whole agent industry stands on — a sign of where the security attention (and the attack surface that matters) has moved.

The fix shipped as coordinated disclosure done right: patched releases 1.14.4 and 1.15.1 landed simultaneously with the advisory (GHSA-776c-mpj7-jm3r, AWS bulletin 2026-015), so days-to-patch for anyone tracking upstream was effectively zero.

CVE-2026-1386: a symlink overwrite in the jailer's init copy​

The second bug is in a completely different layer: not the VMM's device emulation but the jailer, Firecracker's privilege-dropping harness. The jailer's job is to chroot the VMM process, place it in its own cgroup and namespaces, drop privileges to a target uid/gid, and copy the Firecracker binary into the jail — all before the VMM ever touches guest config. It is the last thing standing between a compromised VMM process and the host.

During that initialization copy, the jailer followed symlinks (and hardlinks) planted in the pre-created jailer directories. A local host user with write access to those directories could get the root-running jailer to overwrite arbitrary host files during startup. The fix (upstream PR #5631, released in 1.13.2 and 1.14.1 alongside AWS bulletin 2026-003) refuses symlinks and hardlinks at the destination path and changes ownership of the copied binary to the specified uid/gid.

Note what this CVE is not: it is not a guest breakout. The attacker is already on the host with write access to jailer directories — a host-hygiene failure, not a sandbox escape. That is precisely why it matters for a different reason than CVE-2026-5747. The virtio-pci bug tests whether the VMM contains a malicious guest; the jailer bug tests whether the host contains a malicious local user. AWS's own services were not impacted "as we appropriately restrict access to the host and the jailer folder, blocking the preconditions required for the attack" — and the published workaround for anyone who cannot upgrade immediately is exactly that: lock the jailer folder down with Unix permissions so only trusted users can write to it.

Two CVEs, two attacker positions (guest root vs. host-local user), two layers (device emulation vs. launch harness). That is the pattern worth sitting with.

Two bug classes, two different trust layers​

Firecracker's isolation story has always been a stack, not a single wall: KVM hardware virtualization at the bottom, a minimal device model (~50,000 lines of Rust against QEMU's ~1.4 million lines of C, per the NSDI 2020 paper) and per-thread seccomp filters in the middle, and the jailer's chroot/cgroup/namespace/privilege-drop wrapper on the outside. Each layer assumes the one inside it is already hostile. The 2026 pair is instructive because each CVE breached a different layer while the others held:

This table is also why "first two application-level escape CVEs" is the right framing. Earlier virtualization scares in this space (the KVM-layer ITScape/Januscape class) lived below Firecracker's code; these two live in it. A 2026 comparative study of AI code sandboxes had to revise its own methodology baseline mid-stream: where it once read "Firecracker has no published hypervisor-escape CVE," it now records two escape-class primitives in the same year. Neither demonstrated full RCE — but both cross the host boundary, and the baseline is gone.

The defense-in-depth moral cuts both ways. Optimistically: layered design worked as designed — a VMM compromise still lands inside a chroot with dropped privileges and a ~24-syscall seccomp filter, and the jailer bug still needed a host foothold no properly operated fleet grants. Pessimistically: 2026 proved every layer is written by humans, including the ~50K-line codebase whose smallness was itself cited as a security argument. Small is better than big — QEMU's 1.4M lines remain a far larger target — but small is not zero.

The operator checklist: what to do this week​

If you run Firecracker directly (self-hosted E2B-style fleet, custom agent sandbox on owned hardware) or depend on someone who does, here is the concrete posture these two advisories imply:

1. Pin Firecracker at or above the fixed releases. That means ≥ 1.14.4 on the 1.14 line (which includes both fixes) or ≥ 1.15.1 on the 1.15 line — 1.14.1 fixed only the jailer bug, so "we upgraded in January" is not sufficient against the virtio-pci bug. Audit forked or derivative VMM code too; AWS's bulletin explicitly calls this out.
2. Decide PCI vs. MMIO explicitly, per fleet. If you enabled --enable-pci for I/O throughput, you bought performance with attack surface — a legitimate trade now that it is patched, but write it down as a decision with an owner, not a flag someone set once. If you never enabled it, confirm that in your fleet config and note MMIO as a deliberate default.
3. Lock jailer directories to owner-only. chown the jail tree to the jailer user and strip group/other write, whether or not you have upgraded — this is both the official workaround and permanent hygiene. No untrusted host account should ever write where the jailer copies from.
4. Treat snapshot images as untrusted input. CVE-2026-5747's worst case explicitly involves "specific snapshot configurations." If your sandbox fleet restores tenant-influenced snapshots (pause/resume, pre-warmed pools), that path deserves the same suspicion as any deserialization boundary: validate, version, and regenerate snapshots from known-good sources.
5. Subscribe to the disclosure channel, not the CVE feed. Both fixes shipped simultaneously with their GitHub advisories — the operators with zero exposure window were the ones watching firecracker-microvm/firecracker security advisories and upgrading on release day, not the ones waiting for a CVE to appear in a scanner weeks later.
6. Ask your vendor the version question. Running sandboxes on E2B, Vercel Sandbox, or any managed Firecracker substrate? "Which Firecracker release are my sandboxes on, and what is your patch SLA after an upstream advisory?" is now a diligence question with two concrete precedents behind it. Self-hostable does not mean self-patching.

The settled argument is now a maintenance contract​

Stepping back: nothing about 2026 suggests teams should leave microVMs for containers-plus-seccomp (weaker boundary, larger shared-kernel surface) or retreat to full QEMU (stronger feature set, ~28x the code). The microVM remains the best isolation-per-millisecond-boot tradeoff in production — ~125 ms boot, ~5 MiB overhead, hardware boundary — which is why every serious agent-sandbox platform converged on it.

What changed is epistemic, not architectural. "It's a microVM, not a container" used to function as a settled argument: the substrate had no escape CVEs, so the conversation ended there. Now it functions as the opening of a maintenance contract: the substrate has had two, both patched same-day by a responsive upstream, and your side of the contract is version pinning, jailer hygiene, transport choice, and advisory monitoring.

That is not a worse position — it is the normal position every isolation boundary eventually reaches. Containers reached it years ago (the runc CVE clusters of 2024–2025). MicroVMs just joined the club.

Two forward-looking notes for the contract's next terms. First, the device-model surface is about to grow: GPU-backed agent sandboxes will push Firecracker-class VMMs toward richer device emulation (the DRA/partitionable-device world Kubernetes is building), and CVE-2026-5747 is a preview of where bugs in that growth will live — device-state validation, not the hypervisor core. Second, upstream fuzzing posture is still thin: Firecracker's fuzzing feature flag is a build hook for external fuzzers, not an in-tree harness run in CI. After the year the zero-CVE baseline broke, that gap is the most obvious next investment for the ecosystem — and the most reasonable thing for heavy consumers of the substrate to fund or contribute.

Patch to 1.14.4+ or 1.15.1+, lock down the jailer dirs, and keep the microVM — just stop treating it as magic.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent sandboxes are part of that future: infrastructure your AI operators can drive through APIs instead of tickets. Star the repo on GitHub or deploy your first app today.