--- title: Firecracker VM Escape: PwnEscape Part 2 | daily.dev description: A guest escape from Firecracker v1.16.1 achieved root code execution on the host, demonstrated as CVE-2026-99999. The exploit chain walks Extended Page Tables... canonical: https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Firecracker VM Escape: PwnEscape Part 2 | daily.dev og:description: A guest escape from Firecracker v1.16.1 achieved root code execution on the host, demonstrated as CVE-2026-99999. The exploit chain walks Extended Page Tables... og:url: https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv og:image: https://api.daily.dev/og/posts/SfK93CSxv.png og:image:alt: Firecracker VM Escape: PwnEscape Part 2 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Firecracker VM Escape: PwnEscape Part 2 **[Hacker News](https://daily.dev/sources/hn)** · 12 min read · 1 upvotes · 0 comments ## Summary A guest escape from Firecracker v1.16.1 achieved root code execution on the host, demonstrated as CVE-2026-99999. The exploit chain walks Extended Page Tables to find the guest page in host memory, reverse-maps host page tables to locate the Firecracker process, locates the Firecracker binary under ASLR, then overwrites the saved pt_regs of the vCPU thread while it is blocked in KVM_RUN. A serial port write triggers the return, causing Firecracker to execute an attacker-chosen call with its own privileges. The VM stayed alive and SSH-responsive after the trigger. The configuration had no jailer; deployments using namespaces and seccomp require separate assessment. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does a Firecracker VM escape exploit the KVM_RUN ioctl to redirect host thread execution? While a vCPU thread is blocked inside the KVM_RUN ioctl, the host kernel stores its saved userspace registers in a pt_regs structure. An attacker with access to host physical memory can locate that frame by searching for a saved instruction pointer matching the Firecracker ioctl continuation, then overwrite RIP, RSP, and argument registers. When a guest operation causes the thread to return from KVM, the kernel restores the modified registers and Firecracker executes the attacker-chosen call. _Researchers tracking hypervisor escape techniques and KVM internals follow developments like this on daily.dev._ ### What multi-stage address resolution chain does a Firecracker guest use to find the host process in memory? The chain has four stages: an EPT resolver walks Extended Page Tables to translate a known guest physical address to a host physical address using a nonce for verification; a reverse mapper searches host page tables for that physical page and recovers the process PGD and virtual address; an image mapper identifies the Firecracker ELF and recovers its ASLR load bias; and a frame finder searches for a pt_regs frame whose saved fields match an active KVM_RUN ioctl in that process. _Teams assessing microVM isolation boundaries find exploit chain breakdowns like this on daily.dev._ ### Does the Firecracker VM escape via CVE-2026-99999 work when the jailer is enabled? The demonstrated exploit targeted a configuration with no jailer, where Firecracker ran directly as root under systemd-run. Firecracker's production containment uses the jailer to drop privileges and restrict the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising the VMM, so the root execution result does not directly apply to jailed deployments. _Security engineers evaluating Firecracker deployment hardening track advisories and research like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 98 comments across hackernews (as of 2026-11-07). **TL;DR:** Discussion centers less on the exploit's novelty (many note it's a known bug, PwnEscape, being demonstrated in practice) and more on whether it's really a Firecracker flaw versus a Linux kernel networking bug, alongside a long tangent about microkernel/hypervisor alternatives like Nova and seL4. **Sentiment:** 10% positive · 35% mixed · 55% skeptical **The case for** - Several consider it a well-documented, technically interesting write-up on a genuinely important vulnerability class. - Some note the jailer and seccomp sandboxing would significantly raise the bar even if this specific chain doesn't defeat them. **The pushback** - Multiple commenters argue the root cause is a Linux kernel networking/virtio-net bug, not a Firecracker-specific flaw, calling the framing misleading. - Some dismiss the writeup as thin, sensationalized, or 'LLM slop' lacking technical depth. - Skepticism that the published proof-of-concept actually demonstrates the claimed exploit chain rather than just using /dev/mem directly. - Concern that running without a jailer is an insecure configuration, so real-world impact on properly hardened deployments is unproven. **By community** - hackernews (heated): Heavy disagreement over whether this is truly a Firecracker vulnerability versus a kernel networking bug, plus skepticism about the writeup's quality and a long sidebar debate about microkernel/hypervisor security philosophy. **Hottest debate:** Whether this is fundamentally a Firecracker vulnerability or simply a Linux kernel networking bug that happens to be demonstrated via Firecracker. **Open questions** - What exactly would be required to defeat the Firecracker jailer and seccomp restrictions to achieve full host compromise? - What are the full memory-write primitives used in the exploit chain, which the writeup doesn't fully detail? **Highlights** > I really wish they would have expanded on this paragraph in their article further: > 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. If I'm understanding all of this correctly, a properly jailed and configured firecracker instance would greatly reduce the blast radius of this escape, and I feel as though it would have been good for them to explain what jailing and dropping privileges would do to help. I'd hope most production firecracker deployments would be doing this already. Not saying that this is any less severe and the root issue is not specific to Firecracker, but to a flaw in the kernel's network code -- they just used an insecure firecracker configuration to demonstrate it. However, I feel like some are taking this as a flaw with firecracker when its not. This is an issue in the kernel networking stack. > — [scoodah on hackernews · 4 comments](https://news.ycombinator.com/item?id=50398529) > Nope. The exploit compromises the host kernel. The researchers built an unconventional exploit chain in which they used the host kernel compromise to compromise the host firecracker userspace code, but I see no fundamental reason they couldn't have compromised something else in the host kernel. > — [amluto on hackernews · 1 comments](https://news.ycombinator.com/item?id=50399255) > It's very much a Firecracker thing. KVM is part of the Firecracker stack, and getting code execution behind the jailer is still effectively game-over; it's just a somewhat higher degree-of-difficulty game-over. It's a drastically worse place than you would have been last year, when there wasn't a known plausible way to get even that far. This is a really good bug and nobody should downplay it. > — [tptacek on hackernews · 1 comments](https://news.ycombinator.com/item?id=50400855) > The actual vulnerability got very little discussion. It's clever. Because Linux networking people are obsessed with checksum performance, virtio-net plumbs checksum offload metadata through the host/guest driver interface. Guests can thus deliver the host packets along with instructions on what to checksum. The vulnerability is a missing sanity check that allows checksum instructions to instruct the host to overwrite the header length field in the IPv4 header, rather than the checksum field. Crucially, this happens in the middle of packet processing, so the kernel code is forced to work with two different ideas of how long the IPv4 header is. All hell predictably breaks loose. > — [tptacek on hackernews · 1 comments](https://news.ycombinator.com/item?id=50398342) > AIUI they’ve chosen as their target the host userspace pt_regs, i.e. the kernel structure that stores Firecracker’s register state. If they can find it and write to it, they can control the complete register state of Firecracker. I assume they chose it as their target because Firecracker, like most Linux KVM userspace [0], maps guest memory into its own address space, giving an easy place to write gadgets. My personal favorite thing to poke into pt_regs is an actual privileged (CPL0) context. [1] Returning from the kernel right back to a controlled kernel context is allowed by the CPU :) [0] Until fairly recently this was mandatory. These days it’s possible to ask KVM to map something into the guest without having it in host userspace memory. [1] Corrupt pt_regs so it executes user memory in kernel mode: https://seclists.org/oss-sec/2015/q3/291 I think this may be my favorite of all exploits I’ve ever written. In fact, I often made a point of not writing interesting exploits for corruption bugs I found, but this one was too much fun to pass up. > — [amluto on hackernews](https://news.ycombinator.com/item?id=50401490) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50397219) · 195 points · 98 comments - [hackernews](https://news.ycombinator.com/item?id=50381397) · 5 points · 0 comments ## Similar posts on daily.dev - [New Linux kernel flaw allows VM escape on Intel, AMD devices](https://daily.dev/posts/new-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices-pgteqqq1i) · BleepingComputer · 2 upvotes · 0 comments - [Repeated VM Escapes By GPT-5.6-Cyber Based Agents Prove VMs and OS' Require Better Maintenance](https://daily.dev/posts/repeated-vm-escapes-by-gpt-5-6-cyber-based-agents-prove-vms-and-os-require-better-maintenance-xbq0n2l3b) · InfoQ · 1 upvotes · 0 comments - [16-year-old KVM flaw allows attackers to escape VMs and take over Linux servers](https://daily.dev/posts/16-year-old-kvm-flaw-allows-attackers-to-escape-vms-and-take-over-linux-servers-gx1scspvh) · CSO Online · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#firecracker](https://daily.dev/tags/firecracker) [View this post on daily.dev](https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Firecracker VM Escape: PwnEscape Part 2","url":"https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv"},"datePublished":"2026-11-06T20:19:44.102Z","dateModified":"2026-11-07T04:37:09.523Z","description":"A guest escape from Firecracker v1.16.1 achieved root code execution on the host, demonstrated as CVE-2026-99999. The exploit chain walks Extended Page Tables...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f413335ea206d751af4821df7406b225?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f413335ea206d751af4821df7406b225?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,firecracker","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Firecracker VM Escape: PwnEscape Part 2"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/firecracker-vm-escape-pwnescape-part-2-sfk93csxv#faq","mainEntity":[{"@type":"Question","name":"How does a Firecracker VM escape exploit the KVM_RUN ioctl to redirect host thread execution?","acceptedAnswer":{"@type":"Answer","text":"While a vCPU thread is blocked inside the KVM_RUN ioctl, the host kernel stores its saved userspace registers in a pt_regs structure. An attacker with access to host physical memory can locate that frame by searching for a saved instruction pointer matching the Firecracker ioctl continuation, then overwrite RIP, RSP, and argument registers. When a guest operation causes the thread to return from KVM, the kernel restores the modified registers and Firecracker executes the attacker-chosen call. Researchers tracking hypervisor escape techniques and KVM internals follow developments like this on daily.dev."}},{"@type":"Question","name":"What multi-stage address resolution chain does a Firecracker guest use to find the host process in memory?","acceptedAnswer":{"@type":"Answer","text":"The chain has four stages: an EPT resolver walks Extended Page Tables to translate a known guest physical address to a host physical address using a nonce for verification; a reverse mapper searches host page tables for that physical page and recovers the process PGD and virtual address; an image mapper identifies the Firecracker ELF and recovers its ASLR load bias; and a frame finder searches for a pt_regs frame whose saved fields match an active KVM_RUN ioctl in that process. Teams assessing microVM isolation boundaries find exploit chain breakdowns like this on daily.dev."}},{"@type":"Question","name":"Does the Firecracker VM escape via CVE-2026-99999 work when the jailer is enabled?","acceptedAnswer":{"@type":"Answer","text":"The demonstrated exploit targeted a configuration with no jailer, where Firecracker ran directly as root under systemd-run. Firecracker's production containment uses the jailer to drop privileges and restrict the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising the VMM, so the root execution result does not directly apply to jailed deployments. Security engineers evaluating Firecracker deployment hardening track advisories and research like this on daily.dev."}}]} ```