Security · Firecracker

PwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailer

The researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.

By BoneFriday 6 November 20263 min readSecurity

entryread only

filedFriday 6 November 2026

length3 min

sectionSecurity

subjectFirecracker

sourceson the page

The researchers behind the kernel bug we covered on 21 October have published the other half of the chain, and their summary is blunt: “Firecracker is supposed to keep untrusted code inside a microVM. We escaped it and achieved code execution as root on the host.”

What the second half adds

Part 1 delivered a primitive that reached host memory. This post uses it “to find Firecracker in memory and take over a live thread from inside the guest”, and then the details matter: “We found how it saved registers, changed where it would resume, and made it execute a call of our choosing when it returned from KVM.” The call runs inside the VMM, on the host, in the process that is supposed to be the boundary.

The detail that matters operationally: “The guest then restored the temporary stack changes.” Firecracker kept running, and the VM stayed reachable over SSH. An escape that leaves the service up is quieter than one that takes it down.

What they tested

“The target was Firecracker v1.16.1 on x86-64, with host kernel 7.0.0-1011-aws and guest kernel 6.18.44+.” The VMM in that test was not sandboxed in the usual way either: “We launched Firecracker directly as root under systemd-run and pinned it with taskset.” That is why the payload had the privilege it did, as the post says: “Consequently, the controlled call executed as root on the host.”

Both of those are properties of the tested setup, not of every Firecracker deployment. An unprivileged VMM gives the attacker whatever that process holds, which is a different and smaller thing than root.

The containment question, left open

The researchers state the limit of their work themselves. “The configuration used here had no jailer.” They then describe what production containment adds: “Firecracker’s production containment includes dropping privileges and restricting the process through namespaces and seccomp.” And the sentence that stops anyone quoting this post as a jailer bypass: “A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.”

What the jailer is, from Firecracker’s own documentation: “The jailer is a program designed to isolate the Firecracker process in order to enhance Firecracker’s security posture.” It is the control under discussion, and nobody has yet tested this chain against it.

What to take from it

The kernel patch still closes the entry point. Part 2 begins with a host-memory primitive that the October bug provides, so a patched host has nothing for this chain to stand on, which is the same conclusion as the first piece and worth restating because the second half does not change it.

Past that, the durable lesson is about how the VMM runs rather than about this specific exploit. Firecracker ships a jailer whose stated job is to isolate the process, and a VMM running as root gives an escape root’s reach. Neither of those is a patch; they are how the process should already be running.

What is not known is worth stating plainly: no new CVE appears here, no vendor advisory was collected, and the source describes no Firecracker release that fixes the chain. The researchers call it “a continuation to show CVE-2026-99999 on a Firecracker setup”, which is exactly the right size for it.

Sources: PwnEscape Part 2 and Firecracker’s jailer documentation.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityAlpine's sshd could be logged into without a password, and the upgrade alone does not close itAlpine's advisory of 5 November describes a password authentication bypass in sshd built without PAM on musl: an attacker who can reach the SSH port logs in with a very long password as an account whose password field is *, provided another account on the machine has a $5$ or $6$ hash. Upstream OpenSSH 10.6p2 calls it a critical security workaround and puts the root cause outside sshd. Alpine's fixed packages run from edge 10.6_p2-r0 back to 3.16 9.0_p1-r6, the upgrade is not complete until sshd is restarted, and no CVE had been assigned.

SecuritySourceHut's closed registration was closed in the page, not in the handlermeta.sr.ht before 0.89.0 still accepted POST /register/step2 on instances whose operator had disabled registration: the handler returned the closed message on every error path but did not check the setting on the success path, and a CSRF token lifted from /login made the request work. Email confirmation still applied where SMTP was configured. NVD scores it 5.3 Medium on its primary CVSS 3.1 metric and fixes 0.89.0, and nothing collected shows exploitation.