Firecracker microvm escape via kvm register manipulation

Security researchers have demonstrated a critical vulnerability in Firecracker, the open-source virtualization technology used to power serverless computing platforms. By manipulating saved CPU registers during a specific kernel transition, they achieved code execution as root on the host machine. The exploit, detailed in November 2026, allows an attacker inside a guest virtual machine to take control of the host process managing that VM without crashing it or alerting standard monitoring tools.

What happened

The research team, publishing under PWN.AI Security Research, released the second part of their "PwnEscape" series. This work builds on a previously disclosed memory primitive that allowed a guest to read and write selected host physical memory. In this follow-up, they chained that primitive with a technique to locate and modify the live execution state of the Firecracker process on the host. The target was Firecracker version 1.16.1 running on an x86-64 system with Linux kernel 7.0.0-1011-aws.

The exploit does not rely on traditional buffer overflows or software bugs in the application logic. Instead, it abuses the mechanism by which the Linux kernel saves and restores processor state when switching between the guest VM and the host userspace process. By identifying the exact memory location where the host thread’s registers are stored during a KVM exit, the attackers redirected execution flow. They forced the host process to execute a write system call, printing a specific marker string to its standard error stream. Crucially, after executing this payload, the exploit restored the original register values, allowing the Firecracker process to continue running normally. The VM remained accessible via SSH, and no errors were logged by the host kernel.

How it works

The core of the attack relies on understanding how Virtual CPUs (vCPUs) interact with the host. Each vCPU in a Firecracker microVM corresponds to a thread in the host process. When the guest needs to perform an operation that requires host intervention, such as handling an interrupt or accessing emulated hardware, the thread exits the KVM kernel module and returns to userspace. During this exit, the kernel saves the thread's current state—including the instruction pointer and stack pointer—into a structure called pt_regs.

The attackers used their existing memory access primitive to scan host physical memory for these saved register structures. First, they placed a unique byte pattern, or nonce, in a known guest page. By walking the Extended Page Tables (EPT), they translated the guest physical address to a host physical address. Next, they reverse-mapped the host page tables to find which host process mapped that physical page, effectively identifying the Firecracker process and its memory layout despite Address Space Layout Randomization (ASLR).

Once the process was identified, they searched for a pt_regs frame that matched the expected state of a thread returning from a KVM_RUN ioctl call. They validated candidates by checking the saved instruction pointer against known Firecracker code addresses and ensuring the syscall arguments matched an active KVM request. After locating the correct frame, they modified the saved instruction pointer to point to a write wrapper in the Firecracker binary and adjusted the stack pointer to include their payload arguments. When the guest triggered a KVM exit by writing to the serial port, the host thread resumed at the attacker-controlled address, executed the write, and then returned to its original path via a carefully constructed return sequence.

Key details

• Target Environment: Firecracker v1.16.1 on x86-64, host kernel 7.0.0-1011-aws, guest kernel 6.18.44+.
• Privilege Level: The exploit achieved code execution as root because the test instance was launched directly as root without a jailer or namespace restrictions.
• Stealth: The VM remained fully operational after the exploit; SSH connections persisted, and uptime counters continued normally.
• Memory Primitive: The attack requires a prior ability to read and write specific host physical memory pages from within the guest.
• Validation: Researchers confirmed success by capturing the marker string N8V23M2\n from the host process's stderr while verifying that executable text and shared libraries remained unmodified.
• Recovery: The exploit explicitly restores three modified stack words after execution, leaving no immediate forensic traces in the temporary stack area.

Why it matters

For engineers building serverless platforms or isolated container environments, this demonstration highlights the risks of relying solely on hypervisor boundaries for security. Firecracker is designed for high-density isolation, but this exploit shows that if a guest can breach the memory isolation layer, it can hijack the management thread itself. This is particularly dangerous because the attack does not crash the service, making it difficult to detect through standard availability monitors.

The impact depends heavily on deployment configuration. The researchers noted that their test setup ran Firecracker as root without additional containment layers like seccomp filters or user namespaces. In production environments, these controls limit what an attacker can do even if they achieve code execution. However, the ability to redirect execution flow within the VMM process remains a severe threat, potentially allowing attackers to bypass seccomp policies if they can manipulate syscall arguments or jump to gadget chains within the allowed memory space.

What you can do

• Audit privilege levels: Ensure Firecracker processes are not running as root. Use the built-in jailer to drop privileges and restrict filesystem access immediately upon startup.
• Enable seccomp filters: Configure strict seccomp profiles to limit the syscalls available to the Firecracker process, reducing the attack surface for any potential code execution.
• Use user namespaces: Run Firecracker inside user namespaces to isolate the process from the host root user, limiting the impact of any escape.
• Monitor for anomalous behavior: Implement logging for unexpected stderr output or unusual syscall patterns from VMM processes, although this exploit is designed to be stealthy.
• Stay updated: Track updates from the Firecracker project and apply patches related to memory isolation and KVM interaction handling as soon as they become available.
• Review memory primitives: Investigate how your workload might expose host physical memory mappings to guests and harden those interfaces against unauthorized translation lookups.