Firecracker was open-sourced by AWS in November 2018 and has spent the intervening years quietly running most of what you think of as "AWS serverless." Lambda runs on Firecracker. Fargate runs on Firecracker. AWS App Runner runs on Firecracker. The project has been battle-tested at a scale that almost no other open-source hypervisor has seen.
The design is deliberately narrow. Firecracker is a virtual machine monitor written in Rust that supports only virtio devices, has no BIOS, no legacy device emulation, and no general-purpose guest support. It exists to run short-lived Linux guests with strong isolation and minimal startup latency. That narrowness is the point.
For teams evaluating Firecracker outside the AWS walled garden — through Kata Containers, through Weave Ignite, or as a direct dependency for custom platforms — the security model is worth understanding in detail.
The Minimalism Is the Security Story
Firecracker's binary is about 10 MB. It supports exactly one CPU architecture per build (x86_64 or aarch64), one guest kernel ABI (Linux), and a fixed set of virtio devices: virtio-net, virtio-block, virtio-vsock, virtio-rng, and virtio-balloon. That is the entire device tree. No USB. No PCI emulation. No audio. No graphics. No BIOS or UEFI.
Compare this to QEMU, which ships support for dozens of device models, multiple hardware architectures, BIOS emulation, and a firmware layer. QEMU's source tree is approximately 40 times larger than Firecracker's, and the gap in attack surface follows directly.
Firecracker runs as a normal Linux process and uses KVM for virtualisation. It does not need any special privileges beyond access to /dev/kvm and the jailer sandbox, and it explicitly drops capabilities after setup. The recommended deployment uses the Firecracker jailer, which chroot's the process, applies seccomp filters, and runs it under a low-privilege UID with cgroup limits.
The design choice to write Firecracker in Rust matters. Memory safety bugs in the hypervisor are a recurring source of VM escape vulnerabilities in C-based hypervisors. Rust eliminates an entire class of these without relying on operator diligence.
Track Record Through 2024
Firecracker has had CVEs, but the list is notably short for a hypervisor with Firecracker's deployment footprint.
CVE-2019-18960 was an early issue in the API where a malformed request could crash the VMM. CVE-2021-23653, disclosed in 2021, was a side-channel leak through shared microarchitectural state that affected the balloon device. CVE-2023-35945 was a denial-of-service through specially crafted virtio-net packets, fixed in 1.4.1. CVE-2024-29194, from March 2024, was a denial-of-service in the virtio-net RX path fixed in 1.6.0.
Notably absent from this list is any full VM escape. Through over five years of Lambda-scale exposure, no published CVE has demonstrated an attacker inside a Firecracker guest gaining code execution on the host. That is remarkable. Compare to QEMU, which has had multiple escape-capable CVEs in the same period — CVE-2020-14364 in USB emulation, CVE-2021-3930 in SCSI emulation, CVE-2022-26354 in virtio-vsock — and the gap in attack surface shows up clearly in the vulnerability history.
The Jailer and Seccomp
Running Firecracker raw would be a mistake. The jailer binary that ships with the project is how AWS actually deploys it, and anyone running Firecracker seriously should use it.
The jailer does several things. It creates a chroot environment with only the files Firecracker needs. It sets up cgroups to limit CPU and memory. It drops Linux capabilities to a minimal set. It applies a seccomp filter that restricts Firecracker itself to about 35 syscalls — the ones it actually needs to service a VM. And it switches to a non-root UID before execing Firecracker.
The seccomp filter matters a lot. Even if a hypothetical attacker compromised the Firecracker process from inside a guest, they would find themselves in a userspace process without the ability to make most interesting syscalls. Combined with the chroot and capability drop, the escape-to-host path requires chaining multiple bugs across different isolation layers.
Startup Latency Is a Security Feature
Firecracker's headline performance number is its startup time — typically 125 ms to get a VM to userspace-ready. This matters for Lambda's cold-start metrics, obviously, but it is also relevant to security posture.
Fast startup means you can run each workload invocation in a fresh VM. Lambda does this: a function invocation may reuse a warm VM within the same billing cycle, but cross-tenant reuse is eliminated by design. If workloads cross trust boundaries, you throw away the VM and start a new one. With QEMU's 2-3 second startup, this pattern is uneconomical. With Firecracker's 125 ms, it is the default.
For on-prem or non-AWS deployments using Firecracker through Kata or Ignite, you do not automatically get this operational model — your orchestrator has to decide when to recycle guests. But the latency budget makes the pattern possible.
Memory Safety and the Rust Bet
Firecracker being in Rust is not a marketing point; it is a structural advantage. A review of QEMU's CVE history shows memory corruption bugs — use-after-free, out-of-bounds writes, type confusion — appearing in almost every major release cycle. Rust's ownership model eliminates most of these by construction.
That is not to say Rust programs cannot have bugs. Logic errors, integer overflows (in arithmetic that is not bounds-checked by the language), and unsafe blocks all remain possibilities. Firecracker has unsafe code for the KVM interface and for performance-critical paths, and bugs there have shown up in the CVE list. But the baseline is meaningfully higher.
AWS's internal security testing of Firecracker, described in a 2020 paper and updated informally since, reports that the Rust rewrite of what had been crosvm-derived C code eliminated an entire category of issues that the team had been patching repeatedly.
Where Firecracker Fits
Outside AWS, the most common production path to Firecracker is through Kata Containers with the firecracker hypervisor backend. Kata 3.x supports this well, and the combination gives you Kubernetes-native orchestration with Firecracker's isolation properties. The trade-off is that you give up some Kata features — virtio-fs, for instance, is not supported on Firecracker — in exchange for the minimal attack surface.
Direct Firecracker deployments are rarer and typically involve custom orchestration layers. Fly.io, for example, built their edge platform on Firecracker directly. It is a real option but a heavier lift than running Kata on top.
For single-tenant workloads where the threat model is "our code plus dependencies," Firecracker's benefits are marginal and the compatibility trade-offs are real. For multi-tenant workloads, code execution services, and anywhere you run untrusted workloads at scale, Firecracker's track record is hard to beat.
How Safeguard Helps
Safeguard tracks the hypervisor layer as a first-class component in container scans, including Firecracker version, jailer configuration, and seccomp policy status. We correlate Firecracker CVEs with the Kata or direct Firecracker deployments that would be affected, so a new advisory does not require manual cross-referencing against your fleet inventory. For teams running mixed hypervisor environments — Firecracker for some workloads, QEMU for others, runc for the rest — we normalise the risk picture so you can see which workload classes are running in which isolation tier. If you are architecting a new serverless or multi-tenant platform and evaluating Firecracker against alternatives, we help quantify the attack surface differences against your actual workload profile.