Miri 环境变量写入 target/ 泄露密钥

技术要点

Rust 安全响应团队收到通知：Miri 会把所有环境变量写入 target/ 目录，这使得密钥可能持久化在缓存中。该问题本身不一定是漏洞，但与 GitHub Actions 的缓存行为结合时，可能让密钥泄露给 PR。

这次修复涉及的关键事实如下：

• 短期修复使 Miri 仅保留 CARGO_* 环境变量（排除 CARGO_*_TOKEN）以及 OUT_DIR。
• 该补丁可能尚未在 nightly 上提供；2026-09-22 的 nightly 版本将不再存在此问题。
• Rust 安全响应团队对 GitHub 仓库进行了生态扫描，识别出 1 个存在此问题的仓库，以及 7 个看似不受影响但需谨慎的仓库，并已联系这些仓库的维护者。

判断是否受影响需同时满足：在 CI 中运行 cargo miri；运行 cargo miri 的步骤通过环境变量访问到密钥（作为步骤本身的环境变量传入、在 workflow 的 env 中设置，或通过前面某个步骤以某种方式持久化到环境中）；workflow 缓存了 target 目录（通常通过 actions/cache 或 swatinem/rust-cache 实现）；该缓存可被 PR 访问。

原理与背景

当调用 cargo miri 时，Miri 需要在多次运行之间保留与构建相关的环境变量。当前实现的做法是：把所有环境变量写入 target/。而 target/ 正是被缓存的对象，因此一旦缓存，其中的密钥就会被持久保存。如果你的环境里包含密钥，PR 就能通过缓存访问到它们。

GitHub Actions 允许在多次运行之间缓存目录。典型配置下，main（及其他分支）上的 CI 运行可以写入缓存，而 PR 只能读取缓存（以此防止缓存投毒）。Rust 项目常通过缓存 cargo install 构建的二进制文件、有时缓存 target/ 的内容来加速 CI。

PR 的 CI 可由任何能在仓库打开 PR 的人触发。GitHub 要求第一个 PR 需维护者批准，但后续 PR 会在每次推送时重新运行 CI。任何此前落地过改动的人，都可以触发一次 CI 运行，从缓存的 target/ 中提取信息，然后向该 PR 推送第二个提交来掩盖痕迹。GitHub 有时会在其界面中隐藏被覆盖的提交，使这类攻击更难被察觉。CI 运行日志和被覆盖的提交也会在几个月后被删除。

落地建议

由于扫描可能并不完美，建议运行 Miri 的用户自行检查自己的 GitHub Actions 配置。若满足上文列出的全部条件，即属于受影响情形。

可能的快速修复包括：为该任务禁用缓存；将密钥的作用域限定到该任务中不调用 Miri 的步骤；临时禁用 Miri。完成上述操作后，请清除缓存，并考虑轮换任何可能已泄露的密钥。

从更通用的角度看，即使不运行 Miri，也应确保能够写入公开缓存的任务不访问密钥。许多工具对密钥没有特殊处理，会假设整个环境变量都可以写入文件系统。Cargo/Miri/Rust 并不保证环境变量不会被复制到 target/，因此不应依赖这一保证。除官方 Rust 工具外，构建脚本也可能将环境变量存储到编译产物中。在缓存 target/ 时，值得确保创建 target/ 的过程（任何调用 cargo 的过程）的输入不暴露密钥。标准 cargo build/test 子命令通常不需要任何密钥或令牌，因此这主要是关于不要把密钥作为环境变量暴露给整个任务的谨慎问题。