---
title: PwnEscape Part 2: with the earlier host-memory primitive, researchers took over a Firecracker VMM thread and ran code as root on a host that launched it without jailer | ctxsec
url: https://ctxsec.com/items/pwnescape-part-2-firecracker-vcpu-host-root-without-jailer
description: "PWN.AI's Paulos Yibelo published the second part of the PwnEscape research, showing what the CVE-2026-99999 guest-to-host memory primitive can do against Firecracker. On Firecracker v1.16.1 (host kernel 7.0.0-1011-aws, guest 6.18.44+), launched directly as root under systemd-run with no jailer, the guest located the host process and the saved register frame of a vCPU thread that was inside KVM_RUN, then redirected what that thread executed when it returned to userspace. The demonstration made Firecracker write a short marker to its own stderr as root; the VMM stayed running and guest SSH stayed up. The authors note that Firecracker's production containment \u2014 the jailer, dropped privileges, namespaces and seccomp \u2014 was not used in this setup and would need a separate assessment. This is a research demonstration, not a report of in-the-wild attacks on Firecracker fleets."
status: "research (PWN.AI / Paulos Yibelo, PwnEscape Part 2); demo on Firecracker v1.16.1 launched as root without jailer; builds on CVE-2026-99999"
published: 2026-11-08
---

> PWN.AI's Paulos Yibelo published the second part of the PwnEscape research, showing what the CVE-2026-99999 guest-to-host memory primitive can do against Firecracker. On Firecracker v1.16.1 (host kernel 7.0.0-1011-aws, guest 6.18.44+), launched directly as root under systemd-run with no jailer, the guest located the host process and the saved register frame of a vCPU thread that was inside KVM_RUN, then redirected what that thread executed when it returned to userspace. The demonstration made Firecracker write a short marker to its own stderr as root; the VMM stayed running and guest SSH stayed up. The authors note that Firecracker's production containment — the jailer, dropped privileges, namespaces and seccomp — was not used in this setup and would need a separate assessment. This is a research demonstration, not a report of in-the-wild attacks on Firecracker fleets.

[← Context & Harness Attacks](/context) · [markdown](/items/pwnescape-part-2-firecracker-vcpu-host-root-without-jailer.md)

research (PWN.AI / Paulos Yibelo, PwnEscape Part 2); demo on Firecracker v1.16.1 launched as root without jailer; builds on CVE-2026-99999

2026-11-08

### PwnEscape Part 2: with the earlier host-memory primitive, researchers took over a Firecracker VMM thread and ran code as root on a host that launched it without jailer

- **What this adds:** Part 1 was the Linux kernel IPv4 checksum bug that can give a malicious guest a host-memory primitive (see our [Oct 15 item](/items/pwnescape-cve-2026-99999)). Part 2 shows that primitive can be used to steer the Firecracker process itself when the VMM is running as unconstrained root.
- **For agent and CI sandboxes that use Firecracker:** patch the host kernel for CVE-2026-99999 first, and run Firecracker through its jailer with privilege dropping, namespaces and seccomp rather than launching the VMM as root.
- A deployment that already uses those jailer controls is outside the scope of this demo; do not treat the write-up as a claim that jailer is broken.

Sources: [PWN.AI: Firecracker VM Escape — PwnEscape Part 2](https://www.pwn.ai/blog/firecracker-escape) · [CVE-2026-99999](https://www.cve.org/CVERecord?id=CVE-2026-99999) · [Firecracker jailer documentation](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md)