Full CAP_SYS_ADMIN exposure inside Firecracker-based AI runtime
Firecracker microVM · AI sandbox runtime
Observed: 2025
Analysis of a production AI sandbox environment revealed guest workloads executing as UID 0 with functional CAP_SYS_ADMIN. The security model trusted the Firecracker microVM boundary entirely, with no intra-guest hardening — no seccomp filtering, no AppArmor, no SELinux. Any workload running inside the guest had near-complete control of the VM runtime environment.
Environment
Key Findings
- ●40 of 41 Linux capabilities granted
- ●CAP_SYS_ADMIN functional (not just present)
- ●No seccomp, AppArmor, or SELinux
- ●pivot_root() executed successfully
Technical Details
Capability enumeration confirmed 40 of 41 Linux capabilities granted to the workload process. CAP_SYS_ADMIN was functional — not just present. Testing confirmed unrestricted access to mount operations, namespace creation, overlayfs mounting, and pivot_root() execution.
The BPF subsystem was accessible. Raw packet sockets were available. Fanotify and io_uring were unrestricted. No seccomp BPF filter was attached to any observed process. NoNewPrivs was not set.
Evidence
seccomp: 0
NoNewPrivs: 0
CapEff: 000001ffffffffff
mount("tmpfs", "/tmp/x", "tmpfs", 0, NULL) = 0
mount("/proc", "/tmp/proc", NULL, MS_BIND, NULL) = 0
pivot_root(".", ".") = 0
setns(fd, CLONE_NEWNET) = 0
unshare(CLONE_NEWUSER) = 0Security Implication
The guest environment behaves more like a privileged container than a hardened sandbox. The isolation model assumes the Firecracker hypervisor boundary is sufficient — which may be true for hypervisor-level escapes, but provides no protection against workloads that abuse the guest runtime itself. A compromised or malicious workload gains near-complete control of the VM environment.
Remediation
Disclosure Status
Vendor notified
No — out of scope
Disclosure type
Public research
Exploit achieved
No