这篇文章完整演示了如何在实际环境中利用 Firecracker microVM 的 PwnEscape 漏洞完成逃逸，但评论者指出该漏洞并非新发现，而是数周前就已公开的漏洞，本文只是给出了可操作的利用过程。作者在文中明确说明，测试配置没有启用 Firecracker 的 jailer；生产环境的隔离依靠降低权限，并用命名空间和 seccomp 限制进程；如果启用这些控制，那么在 VMM 被攻陷之后攻击者还能获得哪些权限和资源，需要另行评估。因此，文中展示的可行性只适用于未加 jailer 的配置，不能直接外推到启用完整隔离的生产部署。
背景
Firecracker 是面向多租户云环境的轻量级 microVM 虚拟机监视器；评论指出，生产部署通常会配合 jailer 降低权限，并用命名空间和 seccomp 限制 VMM 进程。该文讨论的 PwnEscape 并非新漏洞，评论称其已在数周前披露，本文重点是在未启用 jailer 的配置下给出实际利用过程。因此，评估该利用的现实影响时，需要把无 jailer 环境与带 jailer 的生产隔离分开看。
社区讨论
评论者 markasoftware 强调，这是对已在数周前披露的 PwnEscape 漏洞的利用实践说明，并非新的漏洞；scoodah 则希望作者进一步展开“本次配置未使用 jailer”这一段，说明经过正确 jailer 与隔离配置的 Firecracker 实例会有什么不同。另有 zX41ZdbW 表示其 ClickBench playground 服务完全依赖 Firecracker VM，托管了数百个数据库引擎，愿意用来做逃逸 PoC；lrvick 则借此主张采用以经过形式化验证的微内核托管 Linux 等复杂内核的 Nova 微虚拟化架构。