Firecracker patches virtio-pci OOB write with host escape risk
TL;DR — A virtio-pci transport out-of-bounds write in Firecracker can let a root guest crash the VMM and, under additional preconditions, potentially reach host code execution.
What happened
Firecracker is AWS’s open-source VMM for running lightweight microVMs (commonly used for multi-tenant and serverless-style isolation).
CVE-2026-5747 describes an out-of-bounds write in Firecracker’s virtio PCI transport. The CVE states that a local guest user with root privileges could crash the Firecracker VMM process or potentially execute arbitrary code on the host by modifying virtio queue configuration registers after device activation.
The record also notes that host code execution is not “free” — it requires additional preconditions (for example, certain custom guest kernel or snapshot configurations), but it is still a high-impact class of bug because it targets the guest/host isolation boundary.
| Item | Source value |
|---|---|
| Affected product | AWS Firecracker |
| Affected versions | 1.13.0 through 1.14.3, plus 1.15.0 |
| Unaffected versions (per CVE record) | 1.14.4, 1.15.1 |
| Affected architectures | x86_64, aarch64 |
| Severity | CVSS v4.0 8.7 (High); CVSS v3.1 7.5 (High) |
Isolation-boundary vulnerabilities in virtualization layers are disproportionately important for platform teams because they can convert a “guest compromise” into a broader host or fleet-level incident, even when the initial attacker is “only” inside the VM.
Who is impacted
- Operators running Firecracker versions
1.13.0through1.14.3or1.15.0. - Environments where guest workloads should be treated as untrusted, including multi-tenant compute where a guest root user is plausible.
- Deployments using guest kernel or snapshot configurations that could satisfy the CVE’s “additional preconditions” for host code execution.
What to do now
- Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
"To remediate this, users should upgrade to Firecracker 1.14.4 or 1.15.1 and later."
- Inventory where Firecracker is deployed (hosts, images, AMIs, container builds, and pinned artifacts) and prioritize upgrades for any nodes running untrusted workloads.
- Treat unexpected Firecracker VMM crashes as a potential signal for abuse until ruled out, and ensure your incident response process can quickly correlate guest activity to VMM/host events.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.