Agent sandboxes increasingly rest on microVMs, so a guest-to-host escape is news for anyone running untrusted agent code. A two-part write-up from pwn.ai, whose second part reached Hacker News on November 6, 2026, describes how a flaw in Linux networking became code execution on a Firecracker host.
The bug is not in the hypervisor
The work began with Vercel's $1 million sandbox challenge, announced August 18. The researchers found that guest-controlled checksum metadata could rewrite an IPv4 header after the kernel had already validated it. The first result was a 32-byte host-memory disclosure, later extended in their lab to selected 64-byte host-kernel writes. Because the path runs through the host's networking stack, the authors argue that KVM itself never has to be exploited.
The Linux fix, commit 6785011f8b16, "ipv4: validate checksum_start before completing checksum", landed October 8. Its message describes the change as a "defence in depth measure" and says "A more complete validation at input is forthcoming". NVD published CVE-2026-99999 on October 15 with a secondary CVSS score of 9.3, and at the time of writing the record still shows a status of Received. The authors say they used an experimental harness in which humans led the work and GPT-5.6 Sol did much of the source-level reasoning.
What Part 2 actually proves
Part 2 starts with that host-memory access and locates a running vCPU thread from inside the guest. It places a recognisable nonce in a guest page, finds the page's host address through the extended page tables, recovers the Firecracker process's page tables, identifies the binary, and then finds the saved registers of a thread sitting in the KVM_RUN call. Changing that saved frame makes Firecracker run a chosen call when it returns from KVM, and the guest stayed reachable over SSH afterwards.
The important limit is stated by the authors. The target was Firecracker v1.16.1 on host kernel 7.0.0-1011-aws, launched "directly as root under systemd-run", and "The configuration used here had no jailer." Firecracker's production containment drops privileges and adds namespaces and seccomp. The authors write that such a deployment "requires a separate assessment of the privileges and resources available after compromising its VMM." So root on the host follows from the test setup. It is not a demonstrated outcome for a jailed deployment.
What remains uncertain. We could not determine Part 2's exact publication date. The authors say the kernel write chain needs a separate article, and they suggest other hypervisor environments are affected, which outsiders cannot yet assess. Upstream describes further input validation as still to come, so a patched kernel may not be the final word.
Analysis: Three actions follow. Confirm the host kernel includes the fix, including any distribution backport. Run the jailer and treat its seccomp and namespace profile as the real boundary, since a compromised VMM has only what that profile leaves. And keep long-lived secrets out of hosts that run guests. If Tanishka's team at Belgavi's Book Store runs a code-writing agent in microVMs, the order database credentials should not be reachable from that host at all.
Sources and evidence
pwn.ai chained a Linux IPv4 checksum flaw (CVE-2026-99999, CVSS 9.3, fix 6785011f8b16 on October 8) into host code execution from a Firecracker guest. The root result came from running Firecracker as root without the jailer, so jailed deployments need their own assessment. Patch hosts, run the jailer, and keep secrets off machines that run guests.