Firecracker microVM escape achieves root code execution on host

pwn.ai researchers have published the second part of a write-up describing a full escape chain out of Firecracker, the microVM technology used to isolate untrusted workloads. Part 1 established a primitive that let code inside the guest read selected host physical memory. Part 2 builds on that primitive to take over the host process that manages the microVM and execute code as root on the host.

The authors first used a known byte pattern (a nonce) planted in a guest page to search the host's Extended Page Tables for the translation root that mapped that page into host physical memory; a broader search turned up two candidate EPT roots, which validation of the nested page tables narrowed to one. From the resulting host physical address, they worked backward through the host's own page tables to find the Firecracker process's address space, then identified the Firecracker binary in memory by matching a known byte sequence in its write(2) wrapper and recovering the load bias caused by ASLR.

With the process and binary located, they searched host memory for the saved register frame (pt_regs) of the vCPU thread that was inside the KVM_RUN system call running their own guest, matching it against the expected return address, stack layout, and syscall fields until a single candidate frame remained. They then modified that saved frame so that when the thread returned from KVM_RUN, Firecracker would instead call its own write(2) wrapper with arguments pointing at a marker string the researchers had placed on Firecracker's private stack, before a short chain of two return addresses reset the return value to zero and resumed Firecracker's original KVM ioctl continuation. Three stack words were saved before this change and restored afterward.

Triggering a single byte write to the guest's serial port caused the vCPU thread to exit KVM_RUN, at which point the kernel loaded the modified registers and Firecracker executed the chosen write call. The host side captured Firecracker's stderr output separately from the guest: it contained exactly the seven-character marker string plus a trailing newline, eight bytes in total, proving code had run under Firecracker's own (root) privileges. Firecracker kept running afterward, the guest's SSH session stayed responsive, and a follow-up check with no further memory changes confirmed the register frame, code and stack state were back to normal with no leftover marker data.

The target was Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws and guest kernel 6.18.44+, launched directly as root under systemd-run. The authors note the setup used in the demonstration ran without Firecracker's "jailer" layer, which in production is meant to drop privileges and restrict the process with namespaces and seccomp. The post frames the chain as a demonstration of an identifier it calls CVE-2026-99999. The source text provided cuts off mid-sentence just as the authors begin discussing what a jailer-protected deployment would require, so the article's conclusion, any disclosure timeline, and any response from Firecracker's maintainers are not covered here.

Key facts

Building on a host-memory-read primitive from Part 1, pwn.ai researchers located Firecracker's process and a live vCPU thread's saved register frame from inside the guest, then rewrote it so Firecracker executed a call of their choosing when the thread returned from KVM_RUN.
The chosen call made Firecracker write a seven-character marker string plus newline (eight bytes total) to its own stderr; the host side captured exactly that output as proof of code execution under Firecracker's root privileges.
Three temporary stack words were modified to stage the call and restored afterward; Firecracker kept running and the guest VM stayed reachable over SSH throughout.
The target was Firecracker v1.16.1 on x86-64 with host kernel 7.0.0-1011-aws and guest kernel 6.18.44+, run without Firecracker's "jailer" privilege-dropping and sandboxing layer.
The post describes the chain as demonstrating CVE-2026-99999; the provided text is truncated before the article's conclusion, so no disclosure timeline or vendor response is included.

Why it matters

Firecracker is a microVM technology that is supposed to keep untrusted code inside the microVM, boxed away from the host. This write-up walks through a complete chain, from a guest-controlled memory read to arbitrary root code execution on the host, built entirely from inside the guest, which goes directly against that isolation promise.

Who it affects

Anyone operating or relying on Firecracker-based multi-tenant infrastructure to isolate untrusted code has a stake in this. The authors are explicit that their demonstration setup had no jailer, the component Firecracker normally uses in production to drop privileges and confine the process with namespaces and seccomp, so the practical exposure of a hardened, jailer-protected deployment is not established by the material available.

How to use it

There is no tool or product here, only a published technical account of an escape chain: locating a guest page in host memory via EPT, pivoting to the host process's own page tables to find Firecracker, identifying a live vCPU thread's saved register frame, and redirecting it on return from KVM_RUN. Defenders can use the description to understand the attack surface around unjailed Firecracker deployments and the role the jailer's privilege-dropping, namespaces and seccomp restrictions play in closing it.

How solid is it

This is a single-source, first-party technical write-up from pwn.ai with detailed pseudocode and a verifiable proof (an exact eight-byte stderr capture), but it is one source and the second part of a series that depends on an unverified primitive from Part 1. The text supplied cuts off before the article's conclusion, so its final claims, any mitigation guidance, and any response from Firecracker's maintainers are not covered. The write-up says it demonstrates CVE-2026-99999, but the provided text gives no further detail on that identifier.

Risks and caveats

The demonstrated configuration ran Firecracker without the jailer component that provides its standard production containment, so it is unclear from the available material whether the same chain would succeed against a hardened, jailer-protected deployment. No information here indicates Firecracker's maintainers have acknowledged, reproduced or patched the issue, and the piece does not state a disclosure timeline.

“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.”

— pwn.ai researchers, PwnEscape Part 2