Rust 安全响应团队收到通知，Miri 会将所有环境变量存储到 target/ 目录，导致机密信息可能持久化在缓存中。

虽然这本身并非漏洞，但与 GitHub Actions 的缓存行为结合时，可能会导致机密信息暴露给 PR。

概述

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

PR CI 可以由任何能在你的仓库上打开 PR 的人触发。GitHub 要求首次 PR 需维护者批准，但后续 PR 会在每次推送时重新运行 CI。任何之前成功合并过更改的人都可以触发一次 CI 运行，从缓存的 target/ 中提取信息，然后通过向 PR 推送第二个提交来掩盖痕迹。

GitHub 有时会在其 UI 中隐藏被覆盖的提交，使这类攻击更难被发现。CI 运行日志和被覆盖的提交也会在几个月后被删除。

当调用 cargo miri 时，Miri 需要在多次运行之间保留与构建相关的环境变量 1 。当前实现此功能的代码将所有环境变量存储到 target/ 目录。当然，当 target/ 被缓存时，这些信息也会持久化。

如果你的环境中包含机密信息，现在 PR 可以通过缓存访问这些信息。

我们的修复

我们的短期修复方案是让 Miri 仅保留 CARGO_* 环境变量（CARGO_*_TOKEN 除外）和 OUT_DIR。长期来看，Miri 和 cargo 可能会找到更好的方式来告知 Miri 相关的环境变量列表。请注意，此补丁可能尚未在 nightly 上可用。

我们还对 GitHub 仓库进行了生态系统扫描，发现 1 个仓库存在此问题，另有 7 个仓库似乎不受影响但仍应保持谨慎。我们已联系这些维护者。

我是否受影响？

我们的扫描很可能并不完善，因此如果你运行 Miri，我们建议你检查自己的 GitHub Actions 配置。

如果你符合以下情况，则存在漏洞：

• 你在 CI 中运行 cargo miri

• 运行 cargo miri 的步骤可以通过环境变量访问 secrets：通过作为环境变量传入该步骤本身、通过在工作流的 env 中设置、通过传入之前的某个步骤并以某种方式将其持久化到环境中

• 所使用的工作流缓存了 target 目录，通常通过 actions/cache 或 swatinem/rust-cache 完成

• 该缓存可被 PR 访问（常见且通常是预期用例）

可能的快速修复包括：

• 为该任务禁用缓存。

• 将 secrets 的作用域限制在该任务中不调用 Miri 的步骤。

• 暂时禁用 Miri。

完成后，请清除缓存。考虑轮换任何可能已泄露的 secrets。

即将发布的 nightly（2026-09-22）中的 Miri 版本将不再有这个问题。

即使你不运行 Miri，也要确保可以写入公共缓存的任务无法访问 secrets。许多工具不会对 secrets 做特殊处理，并假定整个环境都可以写入文件系统。

威胁模型

我们认为，让缓存容易被 secrets 污染是一种不良实践。

如果缓存 target/，值得确保创建 target/ 的进程（任何调用 cargo 的东西）的输入无法访问 secrets。标准 cargo build/test 子命令通常很少需要任何 secrets 或 token 2，因此这主要是一个注意不要让 secrets 作为环境变量暴露给整个任务的问题。

Cargo/Miri/Rust 并不保证环境变量不会被复制到 target/ 中。虽然我们将其视为安全问题并出于谨慎将其修补掉，但一般来说你不应依赖这一点。除官方 Rust 工具外，构建脚本也可能执行一些导致环境被存储到编译产物中的操作。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Rust Blog

原创地址：https://blog.rust-lang.org/2026/09/21/github-actions-leaking-secrets-when-miri-output-is-cached/