Pwn.ai Claims Firecracker VM Escape to Root on the Host

Pwn.ai says it escaped a Firecracker microVM and achieved code execution as root on the host. The claim appears in a post titled "Firecracker VM Escape: PwnEscape Part 2," dated 6 November 2026 and published at pwn.ai/blog/firecracker-escape.

According to the post, the exploit modified saved registers so that Firecracker would execute a chosen call when returning from KVM. Firecracker kept running throughout, and the guest VM remained accessible over SSH. The write-up frames the result as a host-side control path reached from inside the guest, not a crash or a denial of service against the VMM.

The chain has a predecessor. Pwn.ai's Part 1, "PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999)," introduced the host memory primitive on which this work rests. Part 2 follows the next stage: locating the Firecracker process in host memory and taking over a live thread from inside the guest. The company describes the work as a continuation intended to show CVE-2026-99999 on a Firecracker setup, and says Part 2 covers the move from that initial primitive to host control.

For readers who do not work with the stack daily, the context is straightforward. Firecracker is a virtual machine monitor (VMM) that uses Linux KVM, the kernel's hardware virtualization interface, to create and run lightweight virtual machines it calls microVMs. Think of each microVM as a sealed room inside a house, with the host operating system as the house itself. Firecracker's stated mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads. Amazon Web Services developed it to accelerate services including AWS Lambda and AWS Fargate, and the project is open-sourced under the Apache License, version 2.0. New releases are published on its GitHub releases page, typically every two or three months.

The project's own documentation states that microVM security depends on a well-configured Linux host operating system. That sentence matters for this story. The isolation a tenant relies on is not only the hypervisor boundary but also the host kernel, KVM, and the way the VMM is set up on top of them. A host-side escape therefore touches the layer that multi-tenant serverless and container platforms assume is sealed off from guest workloads.

The most useful next step for operators is to treat the claim as a concrete lead rather than as a settled picture. The CVE identifier in the post gives defenders something to search for in their advisory feeds and asset inventories, and the post's description of a live-thread takeover points toward what host-side telemetry and hardening would need to catch. Teams running Firecracker under their own orchestration should map which of their hosts run the affected configuration, and confirm that they are on a release the project has shipped since the disclosure.

The broader context here is familiar to anyone who has followed hypervisor security. Each generation of isolation technology has been judged by whether the boundary holds under a motivated attacker who already has a foothold inside the guest. Lightweight VMs were built to make that boundary cheap enough to use for every function invocation, and cheap multi-tenancy is valuable precisely because it spreads workloads across shared hardware. The same economics reward a researcher who can cross the boundary once and then operate on the host. If the chain holds up, the result is a concrete reminder that a microVM is only as strong as the host configuration and the hypervisor code paths beneath it, and the fix is as much operational as it is a patch.