Wasmtime 两个沙箱逃逸漏洞曝光：跑 WebAssembly 插件的服务为什么要尽快升级

事件概述：WebAssembly 运行时两个月内多次被打破沙箱边界

2026 年 10 月 19 日，Bytecode Alliance 针对其维护的 WebAssembly 运行时 Wasmtime 发布安全公告 GHSA-897f-g5gm-fmxm（CVE-2026-115889），CVSS v3.1 评分高达 9.9（AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H），等级为 Critical。漏洞位于 Wasmtime 默认使用的 Cranelift 编译器后端：该后端对 SSA 值索引做位压缩（bit-packing）存储，在 release 构建中可能发生静默整数溢出，导致中间代码里的值引用错位，形成类型混淆（type confusion），最终让精心构造的 Wasm 模块获得任意误编译效果，直接逃逸沙箱。公告明确说明：使用默认配置（Cranelift 后端）的 Wasmtime，在任意架构和平台上，都可能被恶意构造的 Wasm 模块打穿沙箱。

紧随其后，官方此前发布的另一条公告 GHSA-vqjp-4c8c-hfgg（CVE-2026-115392，CVSS v4 8.8）同样指向沙箱逃逸：Wasmtime 的 wasmtime-wasi 文件系统实现依赖 cap-std 库处理符号链接，尾随斜杠可被用于绕过沙箱，拥有写权限的客户机可以读写宿主进程可访问的任意目录和文件，属于完整的文件系统沙箱逃逸。两条叠加并非孤例——2026 年 4 月 Bytecode Alliance 就曾一次性发布 11 个安全公告（部分由 LLM 辅助审计发现），其中 CVE-2026-34987（Winch 后端）和 CVE-2026-34971（aarch64 Cranelift 误编译）同样是 CVSS 9.0 的沙箱逃逸。短短半年内，Wasmtime 的隔离边界已被多次击穿。

影响范围：谁在真正“跑”Wasmtime

Wasmtime 本身是开源运行时，不是普通站长会直接安装的软件，真正的风险在于把它当作隔离边界来用的平台和产品。常见场景包括：服务网格中的数据面插件（例如 Envoy/Istio 生态的 WASM 过滤器，通过 proxy-wasm 在沙箱里执行扩展逻辑）、各类 Serverless 与边缘函数平台、使用 Wasm 作为插件容器的桌面端和浏览器扩展框架（例如 Extism 一类插件系统）、Kubernetes 场景下通过 containerd Wasm 垫层直接运行 Wasm 工作负载的方案，以及越来越多把“不可信代码跑在 Wasm 沙箱里”当作卖点的 AI 插件与自动化执行环境。

版本上，受 CVE-2026-115889 影响的是 36.0.19 以下、37.0.0 及以上且低于 43.0.0 的全部版本；36.0.19 已修复，43.0 及以后的版本改用完整 u32 索引并加入越界检查，不再受此缺陷影响。文件系统逃逸漏洞 CVE-2026-115392 影响 24.0.12 及以下、25.0.0 至 36.0.13、37.0.0 至 46.0.2、47.0.0 至 47.0.3，修复版本为 24.0.13 / 36.0.14 / 46.0.3 / 47.0.4，48.0.0 起不受影响。需要特别注意的是：文件系统逃逸在 Linux 内核 5.6 以上（使用 openat2 的 RESOLVE_BENEATH）不受影响，但 macOS 和使用旧内核的 Linux 主机会中招，而 macOS 恰好是大量开发者和设计师团队的主机平台。

为什么要关注：沙箱逃逸约等于容器逃逸

对普通用户来说，Wasmtime 听起来很遥远，但理解它的风险模型并不难：引入 Wasm 沙箱的目的，就是把“不可信或半可信的代码”关起来跑。沙箱一旦可逃逸，这套隔离假设瞬间归零——原本只能碰自己一亩三分地的模块，可以直接读写宿主文件、横向接触同机其他进程，危害等级与容器逃逸、虚拟机逃逸同级。

从攻击者视角看，这两条漏洞的门槛也并不高。CVE-2026-115889 的利用前提只是“能让目标 Wasmtime 加载一个恶意构造的模块”（CVSS 中权限要求为 Low），而在插件平台、函数计算、WASM 过滤器这些典型用法里，“接受外部提交的 Wasm 模块”恰恰是产品的核心功能——也就是说，威胁模型里的攻击者，就是平台上的普通使用者或能触达插件上传链路的人。攻击复杂度低、无需用户交互，一旦出现公开可用的利用代码，批量扫描和利用的速度会非常快。

排查思路：先确认自己有没有“裸奔”在旧版本上

排查的第一步不是盯日志，而是盘点资产：你的业务、平台或供应商产品里，有没有以任何形式嵌入 Wasmtime？可以直接使用的检查方式包括：

1）Rust 项目在源码根目录执行 cargo tree | grep wasmtime 或直接查看 Cargo.lock 中 wasmtime 相关条目的版本号；2）使用 Wasmtime CLI 的机器执行 wasmtime --version 查看版本；3）对商用产品，查阅供应商的安全公告或 release notes，确认其内置的 Wasmtime/cap-std 版本是否已在修复线以上；4）如果使用了 WASM 插件功能且运行环境包含 macOS 或内核早于 5.6 的 Linux 主机，对文件系统逃逸漏洞要按高风险对待。

至于入侵迹象，公告未给出专门 IOC。通用的思路是：关注 Wasm 相关进程的异常退出、宿主进程出现段错误或崩溃、插件进程出现计划之外的文件读写与网络外联——这些都不必然是攻击，但值得作为起点结合平台自身日志进一步核实。

修复与缓解建议

两条漏洞的官方态度都很明确：升级是唯一完整修复，没有配置层的临时变通方案（文件系统逃逸一项，官方明确表示“无已知 workaround”）。具体建议按优先级排列：

1）尽快把 Wasmtime 升级到官方修复版本：受 CVE-2026-115889 影响的环境升级至 36.0.19 或直接采用 43.0 及以上；同时对照 CVE-2026-115392 的修复清单（24.0.13 / 36.0.14 / 46.0.3 / 47.0.4 / 48.0+）确认文件系统侧也已修补。2）升级前先在测试环境用真实插件回归验证，评估对业务的影响，选择低峰期执行；涉及生产服务重启的操作，提前做好配置与数据备份，并确认回滚方案。3）在补丁窗口期内，收敛暴露面：限制谁能向平台提交 Wasm 模块，关闭不必要的插件上传/自动加载入口，对沙箱内代码能访问的目录做最小化授权。4）如果暂时无法升级，至少确认运行主机内核版本（Linux 5.6+ 可免疫文件系统逃逸一项），并加密关注供应商补丁节奏。

对自建平台的团队，还应把这次事件当作供应链提醒：Wasmtime、cap-std 这类底层库往往以传递依赖的形式藏在产品里，建议把关键安全组件的版本纳入资产台账，订阅上游安全公告（GitHub Security Advisories），而不是等媒体通报后才反应。

后续观察

截至本文发布，官方公告未提及这两个漏洞存在公开利用代码或在野利用报告，但它们已是安全社区密集跟踪的对象：4 月那一批沙箱逃逸、10 月这条 9.9 分漏洞、以及“报告由 AI 辅助完成”的细节，都说明编译器后端与沙箱边界的攻防已经进入高频对抗阶段。WebAssembly 被越多平台当作隔离卖点，这类漏洞的供应链波及面就会越广。建议涉及 Wasm 插件、Serverless 函数与 WASM 过滤器的团队，把 Wasmtime 升级列入近期维护窗口，并持续关注 Bytecode Alliance 与下游发行版的后续公告——一切版本与缓解结论，以官方公告为准。