Firecracker — микро-VM от AWS, на которых работают Lambda и Fargate, а также множество сторонних песочниц для агентов и CI. Модель безопасности здесь простая: гость не должен дотянуться до хоста, даже если внутри ВМ уже выполняется чужой код.
Уязвимость ломает это допущение: при определённой манипуляции с состоянием vCPU гость может перенаправить выполнение на хосте и получить root. Опубликован working proof of concept для Firecracker v1.16.1 на x86-64.
Почему это не всеобщая тревога
Условие эксплуатации узкое: Firecracker должен быть запущен от root и без jailer. В типовой конфигурации AWS jailer включён, и именно он отделяет процесс микровиртуализации от хоста. Но в самодельных сборках и внутренних песочницах «побыстрее» jailer отключают или запускают всё от root — и тогда граница исчезает.
Что делать
Если вы используете Firecracker напрямую, проверьте, как именно запускаются процессы: с jailer или без, от какого пользователя. Это важнее номера версии, потому что даже исправленная сборка без jailer даёт гораздо больше прав при следующей ошибке.
Дальше — обновление до версии с исправлением и обзор привилегий на хостах: если процесс микро-VM не должен уметь писать в чужие каталоги или читать чужие данные, это стоит закрыть. Для песочниц с недоверенным кодом (агенты, CI, анализ malware) — тем более.
Firecracker is AWS’s micro-VM, used by Lambda and Fargate and by many third-party sandboxes for agents and CI. Its security model is simple: a guest must not reach the host, even when untrusted code already runs inside the VM.
The flaw breaks that assumption: with a particular manipulation of vCPU state, a guest can redirect host execution and gain root. A working proof of concept exists for Firecracker v1.16.1 on x86-64.
Why it is not a general alarm
The exploitation condition is narrow: Firecracker must run as root and without the jailer. In the standard AWS configuration the jailer is enabled, and it is precisely what separates the micro-virtualisation process from the host. But in hand-rolled builds and internal sandboxes set up “quickly”, the jailer is disabled or everything runs as root — and then the boundary disappears.
What to do
If you run Firecracker directly, check how the processes start: with or without the jailer, and under which user. That matters more than the version number, because even a patched build without the jailer gives far more privileges on the next mistake.
Then update to a fixed version and review host privileges: if the micro-VM process does not need to write to other directories or read other data, close that. For sandboxes running untrusted code — agents, CI, malware analysis — all the more so.