The Pulse

PWN Research Reports Firecracker Escape to Root on Host, Run Without Jailer

PWN Research describes a Firecracker microVM escape that redirected a live virtual CPU thread and executed code in the host process. The demonstration ran Firecracker as root without its jailer, a setup the researchers distinguish from prod

AI.info Team · Written with AI · fact-checked · 2026-11-07

Firecracker is supposed to keep untrusted code inside a microVM. PWN Research says its researchers escaped that boundary and achieved code execution as root on the host. The tested configuration, however, ran Firecracker directly as root and had no jailer.

Tracing a guest page into the VMM

The researchers describe the work as a continuation of PwnEscape Part 1. Each virtual CPU has a host thread that enters KVM to run the guest and returns to Firecracker when userspace must handle an event. While that thread runs KVM_RUN, the host kernel holds its saved userspace registers in a structure called pt_regs. The researchers say they used the saved frame to choose where Firecracker would resume after returning from KVM.

They began with a guest page containing a recognizable nonce, then searched candidate EPT roots for a translation to that page. The nonce check connected a proposed translation to memory the researchers controlled. The search produced two candidates, and validation of the nested page tables reduced them to one EPT root. From the guest page’s host address, the reverse mapper recovered a host process address space and the virtual address where that page appeared.

Finding the live vCPU thread

The researchers then identified the Firecracker executable, recovered its load bias and searched for the live vCPU thread’s saved register frame. They checked the candidate frame against the KVM_RUN request, the validated Firecracker instruction address and the recovered host page tables. Their search left one candidate frame, which they passed to a final helper that repeated checks on the code, frame and stack before making changes.

A marker confirms host execution

The researchers chose a write to Firecracker’s stderr as their proof of control. A guest serial-port write triggered the vCPU thread’s return from KVM_RUN, after which Firecracker executed the selected write operation. The host runner captured the marker, and the page says the output contained exactly eight bytes, including the final newline.

After the trigger, Firecracker remained alive, guest SSH responded, and the helper had restored all three temporary stack words. The researchers also report that a fresh validation pass, performed without memory changes, passed its checks after restoration.

The root-run setup limits the claim

The target was Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws and guest kernel 6.18.44+. Firecracker ran directly as root under systemd-run, and the tested configuration had no jailer. The page says Firecracker production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls, the researchers write, requires a separate assessment of the privileges and resources available after VMM compromise.