Miri Turns Rust CI Caches Into a Secret-Handling Boundary

A recent Rust security notice changes how teams should think about CI caching: target/ is not merely a performance artifact when Miri is involved. It can become a secret-handling boundary.

The Rust Security Response Team reported that Miri stored all environment variables in target/ so they could be reused between runs. When a workflow cached that directory, secrets present in the environment could persist in the cache and become readable by pull-request workflows. The issue required a specific combination: CI had to run cargo miri, the Miri step had to receive secrets, and the cached target/ directory had to be accessible to pull requests.

That model matters to ICP developers because canister repositories often optimize Rust CI with dependency and build caches. A cache hit can save minutes, but it also changes the lifetime and audience of files produced during the build. A pull request does not need to alter the cache to benefit from a previously written artifact; it may only need permission to restore it.

The Rust team’s short-term fix limits Miri’s preserved environment to CARGO_* variables—excluding CARGO_*_TOKEN—and OUT_DIR. The notice says the fix was planned for the nightly release dated September 22, 2026, but teams should verify the toolchain they actually run rather than assume the patch is present.

For a repository using Miri in GitHub Actions, the practical response is straightforward:

• Do not expose secrets to the Miri step.
• Disable target/ caching for that job, or scope caching to files that cannot contain credentials.
• After remediation, clear existing caches and rotate credentials that may have been exposed.
• Review build scripts and other tools too: Rust’s notice warns that Cargo and Rust do not guarantee that environment variables will never be copied into compilation artifacts.

GitHub’s documentation separately recommends passing secrets only to the steps that need them and notes that secrets are generally not passed to workflows triggered from forked repositories, except for GITHUB_TOKEN. That protection does not replace cache review: a repository’s own pull-request policy and cache permissions determine who can read previously saved artifacts.

The broader lesson is operational rather than language-specific. A Rust build cache is part of the security perimeter whenever code-generation tools, build scripts, tests, or emulators can observe process state. Treat cache contents as potentially sensitive, design CI jobs around least privilege, and make cache deletion and credential rotation part of incident response.

Caveat: the Rust Security Response Team says its ecosystem scan was imperfect, so maintainers should inspect their own workflows instead of treating the published scan as a complete inventory.