Firecracker VM Escape Puts Root Code Execution on the Host

What the Firecracker VM escape actually does

The end state is blunt: code running as root on the host, outside the microVM that was supposed to contain it.

Firecracker is the lightweight virtualisation layer AWS built to run untrusted code in microVMs. The whole design rests on a simple promise: the guest stays in the guest. PwnEscape Part 2, published by PWN.AI Security Research, describes breaking that promise on a Firecracker setup.

The write-up is the second half of a chain. Part 1 introduced a host memory primitive; Part 2 uses it to find the Firecracker process in memory and take over a live thread from inside the guest. The researchers describe the result as guest-to-host code execution, with the malicious guest crossing the microVM boundary and controlling a root-run host process.

The detail that makes this more than a theoretical paper is what happens afterwards. According to the write-up, Firecracker kept running and the VM remained accessible over SSH. A quiet takeover, not a crash.

From a guest page to the Firecracker process

The first problem is orientation: the guest and the host use different physical address spaces, and the attacker starts with nothing but a page it controls inside the VM.

A page has a guest physical address inside the VM and a host physical address in the machine backing it. Extended Page Tables translate between the two. The researchers planted a recognisable byte pattern, a nonce, in a guest page, then searched host physical memory for candidate EPT roots and walked each one until it reached a page containing that nonce.

The search produced two candidates; validating the nested page tables narrowed it to one. Walking that root gave them the host physical address of their own guest page, which they call guest_page_hpa.

That is a foothold, not a win. Firecracker maps guest memory into its own address space, so the next step runs backwards through the host's native page tables: instead of translating a virtual address to a physical one, the reverse mapper looks for a mapping to the physical page it already knows, then recovers the virtual address and the page table root behind it. One validated address space came back, retained as host_pgd.

Finding the binary and beating ASLR

With a page table root in hand, the guest can read the Firecracker process the way a debugger would.

The next resolver scans those mappings for an ELF image and checks a known byte sequence in Firecracker's write(2) wrapper. That is how the recovered address space gets tied to the binary being targeted rather than some other process.

Address space layout randomisation moves the executable at load time, so the mapper recovers the load bias: the gap between an address in the ELF image and its runtime address. That value, firecracker_base, lets the exploit locate code in the running process and translate virtual addresses to host physical memory to check the bytes match.

Three locations were verified: the write(2) wrapper used to produce proof, the continuation after the KVM ioctl, and a short xor eax,eax; ret sequence needed to return cleanly. Each one has a job in the return path.

Why KVM_RUN is the weak point

Every vCPU in a Firecracker microVM is a thread in a host process, and that thread keeps leaving the guest and coming back.

The thread enters KVM to run the guest and returns to Firecracker when userspace needs to handle an event. While the thread sits in that system call, the host kernel holds its saved userspace registers in a structure called pt_regs. The instruction pointer says where execution resumes; the stack pointer says which userspace stack it uses.

That saved frame is the target. If an attacker can locate and modify it, they choose what Firecracker executes the moment the thread returns to userspace. Any guest operation that forces a return from KVM_RUN becomes the trigger.

The frame finder used host_pgd and firecracker_base to recognise the host thread's saved state, with the return address as the most useful clue. The write-up then describes changing where the thread would resume and making it execute a call of the attacker's choosing on return from KVM, after which the guest restored the temporary stack changes.

How serious is this for cloud users?

The write-up is a technical demonstration, not a mass-exploitation report, and it should be read that way.

The research is tied to CVE-2026-99999 and runs against a Firecracker setup rather than a public cloud region. It also builds on a host memory primitive from Part 1, which matters: the full chain needs more than a single bug in the guest.

The significance is architectural. MicroVM isolation is sold as the boundary that makes running strangers' code safe, and Firecracker sits under a lot of that trust. A demonstrated path from guest to root on the host is exactly the scenario the model is meant to rule out.

Anyone running Firecracker directly, or multi-tenant services built on it, should treat the publication as a prompt to check their patch level and how much they rely on the microVM boundary alone. The researchers have not published a full exploit chain in the material available.

What it means for you

If you rent cloud compute, you do not patch Firecracker yourself; your provider does. The practical question is whether your workloads depend on microVM isolation as the only barrier between tenants. Ask your provider for its response to CVE-2026-99999 and its patch timeline.

If you run Firecracker on your own infrastructure, in the US, UK or EU, the advice is the familiar one: track the upstream fix and do not assume the microVM boundary is sufficient on its own. No affected versions or patch dates have been confirmed in the material available.

Firecracker's reputation rests on a boundary that this research says can be crossed. The chain is intricate and depends on a prior memory primitive, so it is not a one-click cloud break. It is still a clear signal that the isolation layer deserves the same scrutiny as the code it protects.