把不可信代码关进 AWS 开源的 Rust 微虚拟机 Firecracker,几乎成了这几年 Serverless 平台与 AI Agent 在线代码沙箱的标准动作。但安全团队 PWN.AI 刚刚公开了一套名为 PwnEscape Part 2 的利用链,在客户机内部直接劫持宿主机的活跃 vCPU 线程,拿下了宿主机 root 代码执行权限,整个过程连虚拟机的 SSH 连接都没断一下。更反常的事实在于,如果你因此去紧急升级 Firecracker 二进制文件,根本挡不住这次攻击。

8 字节标记与不断连的幽灵劫持

PWN.AI 的测试靶机跑在 x86-64 架构的 Firecracker v1.16.1 上,宿主机内核版本为 7.0.0-1011-aws,客户机内核是 6.18.44+。研究团队承接此前 Part 1 获得的宿主机物理内存读写原语,从客户机内部一步步反向摸清了宿主机的底牌。

从客户机内存经四步寻址反向劫持宿主机线程寄存器(剖面示意)
从客户机内存经四步寻址反向劫持宿主机线程寄存器(剖面示意)

具体路径分四步走完。攻击者先在客户机受控内存页(0x08f03000)写入特定字节特征 nonce,扫描并从两个候选者中验证出唯一的扩展页表(EPT)根,拿到该页在宿主机上的物理地址 0x165610000。接着利用 Firecracker 会把客户机内存映射进自身地址空间的特性,反向检索宿主机原生页表,恢复出 Firecracker 进程的页全局目录(0x14afc2000)。

拿到地址空间后,利用程序通过比对 write(2) 包装器、KVM_RUN 续接点以及 xor eax,eax; ret 序列三处特征字节,算出 ELF 镜像加载偏移 0x7298c2400000,直接绕过 ASLR。最后一步是在宿主机内存里搜寻 vCPU 线程陷入 KVM_RUN 系统调用时保存在内核 pt_regs 结构中的用户态寄存器帧(0x13a5bff48),篡改其指令指针与栈数据。

PwnEscape 宿主机线程劫持四步链路 01 穿透 EPT 客户机页写 nonce 筛出唯一 EPT 根 获宿主机物理地址 0x165610000 02 反向查页表 顺内存映射反推 恢复进程 PGD 拿到页全局目录 0x14afc2000 03 绕过 ASLR 比对三处特征码 定位 ELF 镜像 算出加载偏移 0x7298c2400000 04 劫持 pt_regs 串口写 1 字节触发 篡改返回栈执行调用 复原栈且 SSH 不断 PID 2936 持续存活

当客户机向串口写入 1 个字节触发 KVM_RUN 返回用户态时,被接管的 Firecracker 线程乖乖向自身标准错误流输出了 N8V23M2\n 这 8 字节标记,随后清零返回值并恢复临时修改的 3 个栈字。宿主机上 PID 为 2936 的 Firecracker 进程毫发无损,客户机运行时间停在 1615.72 秒且 SSH 响应如常。

标题写着微虚拟机逃逸,补丁却打在 Linux 2.6.27 上

把这场漂亮的黑客秀直接读成 Firecracker 被攻破,会掉进三个事实盲区。

实验环境以最高权限裸跑,未开启生产标配的隔离机制(剖面示意)
实验环境以最高权限裸跑,未开启生产标配的隔离机制(剖面示意)

支撑整套攻击的底层内存读写原语 CVE-2026-99999,于 2026 年 10 月 15 日由 Linux CNA 正式发布,受影响产品是 Linux 内核,而非 Firecracker 本身。这个漏洞最早自 Linux 2.6.27 引入并已被外部独立复现,上游首个修复版本分布在 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11 及主线 7.3-rc7。

第二个落差藏在运行权限里。PWN.AI 之所以能一击拿下宿主机 root,是因为实验环境通过 systemd-run 直接以 root 身份裸跑 Firecracker,既没降权,也没启用官方标配的 Jailer 隔离组件。而在标准生产规范中,Jailer 会用 chroot、命名空间降权与 seccomp 系统调用白名单把 VMM 进程死死困住。

第三个边界来自商业实战现场。这项研究源于 Vercel 举办的 100 万美元沙箱挑战赛;Vercel 在 2026 年 10 月 14 日的赛事总结中证实,生产环境确实出现了宿主机内存泄露,但宿主机崩溃与管理员级代码执行仅发生在研究人员自建的同配置测试系统上,未在生产环境上演。此外,截至 2026 年 11 月 6 日,虽然底层内核漏洞已获多方印证,但尚无第三方独立复现报告证实 Part 2 这条完整的端到端线程劫持链。

实验室极限演示与生产环境防线的真实落差 PWN.AI 实验室测试环境 • 漏洞底座:宿主机含 CVE-2026-99999 • 进程权限:systemd-run 直接 root 裸跑 • 外围沙箱:未启用 Jailer 与 seccomp 过滤 后果:无感劫持线程,直取宿主机 root 云厂商标准生产规范 / Vercel 现场 • 修复动作:升级宿主机内核而非仅换 VMM • 纵深防御:强制 Jailer 降权与命名空间隔离 • 过滤策略:严格 seccomp 拦截非预期系统调用 实测:生产环境仅证实宿主机内存泄露

拆掉微虚拟机银弹迷思,沙箱地基还得靠慢功夫

我更在意的是,为什么各家 AI 代码沙箱平台总喜欢把采用 Firecracker 当成安全宣传的免死金牌。

云沙箱的安全隐患往往藏在底层宿主机内核与外围胶水层(示意图)
云沙箱的安全隐患往往藏在底层宿主机内核与外围胶水层(示意图)

《韩非子》讲“千丈之堤,以蝼蚁之穴溃”,今天云基础设施的蚁穴往往不在那层光鲜的 Rust 代码里,而在它脚下庞大的宿主机内核与外围胶水层。更何况,即便只看 Firecracker 自身,2026 年内也并非铁板一块:

漏洞编号披露日期影响组件与版本修复版本与关键细节
CVE-2026-999992026-10-15Linux 内核 (自 2.6.27 起)5.10.272 / 6.1.190 / 7.2.11 等宿主机内核修复
CVE-2026-1221922026-11-04Firecracker v0.23.0–v1.16.1v1.16.2 / v1.17.0 修复快照恢复漏洞,AWS 声明 Lambda 不受影响
CVE-2026-57472026-04-07Firecracker 1.13.0–1.14.3, 1.15.01.14.4 / 1.15.1 修复 virtio-pci 越界写 (CVSS 8.7,Xinyang Ge 与 Claude 报告)
CVE-2026-13862026-01-23Firecracker Jailer 组件1.13.2 / 1.14.1 修复符号链接任意宿主机文件覆盖
把安全押在单一组件的名字上,本质上是拿架构选型逃避枯燥的运维基线。

这种盲目崇拜很像当年泰坦尼克号对水密舱的迷信:船体局部设计确实精良,但只要冰山划破的深度越过隔板高度,水照样漫过全船。VEE 2020 的学术研究早就证实,精简如 Firecracker,在网络、存储和内存操作中仍会触发大量宿主机 Linux 内核代码执行。

USENIX Security 2023 的论文《Attacks are Forwarded》同样指出,基于 Kata Containers 与 Firecracker 的容器系统在通过虚拟化与集成层转发操作时,仍会暴露宿主机功能与共享资源;2023 年 11 月 27 日发表的微架构安全评估也表明,虚拟化对特定微架构侧信道攻击保护有限,必须依赖宿主机内核、固件与处理器级缓解措施。把精简 VMM(Firecracker)、用户态应用内核 Sentry 拦截系统调用的沙箱(gVisor)以及底层本就可挂载 Firecracker 的轻量级虚拟机运行时(Kata Containers)做简单线性安全排名,本身就是外行话。

  • 风险.正在托管不可信 AI 生成代码的平台如果只盯着升级 VMM 版本,或者为了图省事在生产环境裸跑 Firecracker、开启非必要的 PCI 特性,一旦遇到 Claude 参与挖掘出的 CVE-2026-5747 或 PWN.AI 串联出的内核级利用链,单租户沦陷就会直接演变成宿主机失守。

回到开头那个不断连的 SSH 会话。PWN.AI 用 8 个字节的错误流输出给所有云架构师提了个醒:接下来真正决定多租户沙箱生死的变量,一来是启用完整 Jailer 与 seccomp 策略后这套 pt_regs 劫持链能否被彻底阻断,二来是在 AI 自动化挖洞工具已经开始批量冲击虚拟化边界的当下,你的宿主机内核补丁周期到底能不能跑赢攻击脚本。