Firecracker vs gVisor vs WASM: What a VM Escape Changes for Agent Sandboxes

Keep the microVM if it is otherwise the right operational fit, but stop treating it as the one boundary that must hold. The PwnEscape Part 2 writeup reports guest-to-host control-flow hijacking on Firecracker v1.16.1, ending in a controlled host call executed as root. The configuration matters: the researchers launched Firecracker directly as root and did not use its jailer. Their result does not prove that a hardened production deployment falls. It does show how expensive it is to skip the containment around the virtual machine monitor.

For teams executing model-written code, the useful response is therefore not an emergency migration from Firecracker to gVisor, containers or WASM. It is to verify Firecracker’s jailer and seccomp layers, assume a VMM compromise is possible, and move the security burden into controls that survive a guest escape: network policy outside the guest, tightly scoped credentials and per-task disposal. None of the sources reviewed here evaluates WASM as an isolation boundary for agent code, so it should be treated as an open question rather than a default refuge.

What PwnEscape Part 2 actually demonstrated

The researchers summarize their result bluntly: “Firecracker is supposed to keep untrusted code inside a microVM. We escaped it and achieved code execution as root on the host.” The full writeup gives the test target as Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws and guest kernel 6.18.44+. Firecracker was launched directly as root under systemd-run and pinned with taskset.

The exploit was not a single, self-contained guest bug in the writeup’s account. Part 2 builds on a host-memory primitive introduced in Part 1, then uses several address-discovery components: an EPT resolver to map guest pages to host memory, a reverse mapper to reconstruct the host address space, an image mapper to find Firecracker despite ASLR, and a frame finder to locate a vCPU thread’s saved state.

That final target follows directly from Firecracker’s KVM architecture. Under KVM, each Firecracker VM maps to a process on the Linux host, and each vCPU is a thread in that process, according to the academic analysis of Firecracker’s security model. The writeup says the researchers modified the thread’s saved userspace register frame, pt_regs, so Firecracker would execute a call of their choosing when the vCPU returned from KVM_RUN:

“We found how it saved registers, changed where it would resume, and made it execute a call of our choosing when it returned from KVM.”

The post-exploitation state is as important for defenders as the technique. The researchers say they restored the three temporarily modified stack words; Firecracker kept running, executable text and shared libraries were left unmodified, and the guest remained accessible over SSH. A healthy-looking guest and a still-running VMM are not evidence that containment held.

There are also real limits. The demonstration produced a controlled call as root, but the authors say that extending the primitive to other calls would require code and arguments compatible with the process’s memory mappings and syscall policy. Most importantly:

“The configuration used here had no jailer. Firecracker’s production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.”

That caveat should shape every severity claim. The writeup frames the work as demonstrating CVE-2026-99999, but it does not provide the CVE’s component mapping, affected-version range, patch status or disclosure timeline. Those facts need verification from the CVE record, Firecracker advisories or a provider advisory before anyone declares a fleet exposed.

What the writeup does not show: a break of a jailed Firecracker deployment, compromise of any managed provider, a universal exploit across versions, or a reason to conclude that another isolation layer is safer without independent evidence.

The microVM was never supposed to stand alone

Firecracker’s own design already assumes that the VMM process needs containment. The Firecracker study describes a jailer that performs setup requiring elevated permissions, including cgroup and chroot configuration, drops privileges and then exec()s the Firecracker binary as an unprivileged process. Seccomp filters are loaded immediately before untrusted guest code starts.

This changes the lesson of the escape. The researchers did not show that the jailer, privilege dropping, namespaces and seccomp all failed together. They showed what a compromised VMM can inherit when those layers are absent and the process starts as root. In a jailed deployment, the same class of VMM compromise should land with fewer privileges and a narrower syscall surface, but no reviewed source tests how much narrower.

That distinction favors hardening evidence over substrate labels. The relevant audit question is not simply “Are we using microVMs?” It is:

• Is Firecracker running under the jailer?
• What user and group own the VMM process?
• Are namespaces, chroot, cgroups and seccomp active?
• Which host resources and device endpoints are reachable after VMM compromise?
• Which Firecracker and host-kernel versions are deployed?
• Has the provider or platform verified the CVE-2026-99999 exposure path?

Firecracker’s small Rust codebase remains a useful design property, but it is not a guarantee. The security-model analysis notes that Firecracker has been assumed to be highly secure because of that design even though earlier flaws, including CVE-2019-18960, were identified. A small codebase reduces the amount of code to audit; it does not remove the need to contain the process when an assumption fails.

Re-scoring the isolation menu

None of the available sources provides a neutral, head-to-head security benchmark for Firecracker, gVisor, plain containers and WASM. A survey of 39 execution-security papers for AI coding agents found that isolation architectures are “almost never” evaluated against one another on a shared benchmark. The following comparison therefore separates mechanisms and reported costs from unsupported claims of superiority.

gVisor is a genuine architectural alternative, not merely a stricter container flag. Its project documentation describes an application kernel that implements a Linux-like interface in memory-safe Go and runs in userspace. It is explicitly not a VM and not just a syscall filter, and runsc plugs into existing OCI workflows.

That convenience carries a different risk shape. Edera’s comparison says gVisor still shares some kernel context, lacks hardware-level isolation and is “often sufficient for defense-in-depth scenarios, but not ideal for adversarial multi-tenancy.” Because Edera sells a competing isolation product, its 10–30% overhead range and suitability judgment should be treated as directional, not neutral.

The same caution applies to Firecracker’s numbers. The under-5 MB overhead, 125 ms boot and 150 microVMs-per-second figures come from a Firecracker study relaying AWS’s own claims of “less than 5MB per container” memory overhead, not from a current comparison against gVisor or WASM. They explain why per-task microVMs can be practical; they do not establish that Firecracker is the safer choice after this disclosure.

Why agent platforms cannot dismiss the result

The result lands on software already used to run untrusted agent workloads. E2B says its sandbox runtime is built on Firecracker with dedicated kernels and a custom memory and snapshot layer, and that it runs untrusted agentic workloads across tens of thousands of parallel sessions. Those are vendor-reported scale claims, and no reviewed source establishes that E2B is vulnerable to the demonstrated chain. The relevance is architectural: Firecracker is production infrastructure for agent execution, not an obscure research target.

Dispose-per-task infrastructure is also already practical. E2B’s engineering publications describe OverlayFS sharing a read-only root filesystem across Firecracker instances, with per-instance writable layers to reduce duplicated storage. On the practitioner side, the Aether background-agent post describes giving each task its own isolated Fly.io VM with a real filesystem, process model and network stack, then shutting the VM down shortly after completion. That post does not identify Firecracker as the Fly.io substrate, so it should not be used as evidence that this escape affects Fly.

The pattern matters more than the provider. Per-task VMs reduce persistence and cross-task contamination, but they do not make a host compromise harmless. A compromised VMM may sit beside many concurrently active tasks, credentials and network flows. Density improves economics while increasing the value of the host to an attacker.

What an escape-class disclosure forces you to verify

The right checklist is mostly independent of whether the next substrate is Firecracker, gVisor or something else.

1. Establish the exact CVE facts. Verify CVE-2026-99999’s affected component and versions, fixed releases, disclosure timeline and relationship to the Part 1 memory primitive. The writeup alone does not supply those facts. Do not infer that a managed provider is vulnerable, patched or unaffected without a provider statement.

2. Audit what a compromised VMM inherits. Confirm that the jailer is enabled and that the VMM runs as an unprivileged process with namespaces, cgroup or chroot confinement and seccomp active. The Firecracker study documents these as part of the production model. A root-launched, unjailed VMM should be treated as a misconfiguration for hostile workloads, not as an acceptable convenience.

3. Move egress enforcement outside the guest. An agent process should not be responsible for enforcing its own network policy. E2B advertises ingress and egress control under customer policy as a product feature, but the evidence does not establish where that enforcement runs in every deployment. For high-risk workloads, prefer an enforcement point in a network path or separate trust domain rather than a process that host root could disable.

4. Measure the policy layer instead of trusting its name. The execution-security survey reports 69–98% failure rates against real denylists. That figure is about denylists, not allowlists, and should not be reused as an allowlist failure rate. It still shows that policy enforcement is a fragile layer that needs adversarial testing. A default-deny egress allowlist is the stronger design goal, but it needs its own tests for DNS, redirects, proxies, package registries and provider-specific metadata paths.

5. Scope credentials to the task and keep them short-lived. This is an inference from blast radius rather than a measured result from any reviewed source. If one guest or VMM compromise can expose more than one task’s authority, ambient cloud credentials and broad tokens turn a local failure into an account-level one. Issue only the permissions the task needs, bind them to the task where the platform supports it, and expire them with the run. E2B’s secrets-vault feature is an example of the product direction, not independent proof that a deployment scopes credentials correctly.

6. Dispose compute and writable state per task. Aether’s one-VM-per-task model and E2B’s OverlayFS layout show the operational pattern. Disposal limits persistence and reuse; it does not protect data exposed while the task is alive. Secrets should expire even if the VM is destroyed on schedule.

7. Do not use liveness as an integrity signal. The escape demonstration left Firecracker running, restored temporary stack changes and preserved guest SSH access. Health checks can confirm availability while missing a control-flow compromise.

8. Benchmark the alternatives on your workload. The survey’s finding that isolation layers are almost never tested against one another means there is no general evidence-backed winner here. Measure syscall-heavy and I/O-heavy agent workloads under your actual image, orchestration path, snapshot behavior and policy enforcement before treating a migration as a security improvement.

What this evidence can say about WASM

Nothing in the available evidence evaluates WASM as a sandbox layer for agent code, and no source compares it with Firecracker or gVisor as an isolation boundary. That absence is not evidence that WASM is unsafe, and it is not evidence that it would have resisted this Firecracker chain. Available Wasm performance evidence comes from a study of QUIC encryption in WebAssembly, which cites PolyBench/C figures of within 20% (x86-64) and 35% (Armv8) of native execution time and accounts for host-function-call and memory-copy costs at the host boundary. Its own measurements cover cryptography throughput, not sandbox security, and it describes the isolation mechanism only in passing: a Wasm module runs isolated from the host in its own linear memory and interacts with the host only through explicit imports and exports. A description of the mechanism is not an assessment of it.

The practical answer is narrower: do not migrate to WASM because of this writeup unless independent WASM evidence supports the move for your workload. A real comparison would need primary documentation and current research on its runtime boundary, host-call surface, resource limits, memory-safety assumptions, ecosystem maturity and performance under agent workloads. Until then, WASM belongs in the decision matrix as unscored, while egress control, credential scoping and task disposal remain necessary whatever substrate is chosen.

Choosing the layer now

For an existing Firecracker-based agent platform, I would keep per-task microVMs when the jailer, privilege drop, namespace restrictions and seccomp policy can be verified, and I would treat network policy and credential lifetime as primary containment rather than accessories. The demonstrated escape does not justify an evidence-free emergency migration. It does justify pausing any configuration that runs the VMM as root without the jailer.

For a platform already standardized on Docker or Kubernetes, gVisor may be the easier additional isolation layer to operate, with the reported 10–30% I/O-heavy overhead treated as a vendor-supplied range to reproduce locally. For adversarial multi-tenant workloads, the vendor comparison’s warning about the lack of hardware isolation should carry weight. Plain containers should not be the sole boundary for code that may be malicious, a conclusion directly consistent with gVisor’s warning that containers are not a sandbox.

The unresolved severity facts still matter. Before assigning urgency, verify CVE-2026-99999’s patch and affected-version status and test or obtain an assessment against a jailed configuration. The durable decision is broader than this one disclosure: choose the substrate for its mechanism and operational cost, but design the platform as though any one isolation layer can fail.

Frequently Asked Questions

Did the researchers test Firecracker with the jailer enabled?

The configuration used here had no jailer. Firecracker’s production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.

What performance overhead does gVisor introduce?

Edera reports 10–30% syscall-interception overhead on I/O-heavy workloads; Edera sells a competing hypervisor, so treat the range as directional

Is WASM a proven alternative for agent sandboxes?

Nothing in the available evidence evaluates WASM as a sandbox layer for agent code, and no source compares it with Firecracker or gVisor as an isolation boundary. That absence is not evidence that WASM is unsafe, and it is not evidence that it would have resisted this Firecracker chain.