Miri Wrote Every Environment Variable to target/, and CI Cached It

Rust’s Security Response Team is telling Miri users to clear their CI caches. Miri writes every environment variable into target/, and target/ is one of the directories Rust CI setups most like to cache.

A workflow that does both lets anyone who can open a pull request read the environment that job was handed. The team’s scan turned up 1 repository with the exposure and 7 that look clean but should be careful anyway.

The step running cargo miri sees secrets as environment variables, either passed to it directly or persisted by an earlier step. The workflow caches target/, usually through actions/cache or swatinem/rust-cache, and PRs can read that cache.

GitHub requires maintainer approval for a first PR, but later PRs rerun CI on every push. So anyone who has already landed a change can pull the cached variables and bury the evidence under a second commit — overwritten commits are sometimes hidden, and logs and overwritten commits are deleted after a few months.

Editor’s note: what I would check first in my own workflows is whether the job that runs Miri is the same job that gets handed secrets. I scope secrets to whole jobs far too casually, and that is a one-line fix I keep postponing.

Our Take: scope secrets to the steps that actually call cargo, then clear the cache and rotate anything that might have leaked. Miri’s short-term patch keeps only CARGO_* variables, minus CARGO_*_TOKEN, plus OUT_DIR. The nightly dated 2026-09-22 is the release that carries it.

The team’s line is the one I keep: “We consider it bad practice to have a cache that can easily be tainted by secrets.” That holds well past Miri: standard cargo build and test subcommands rarely need secrets, and most tooling assumes the whole environment can end up on disk.

A cache PRs can read is a public folder. So open your workflow files and look at what the job holding the target/ cache can actually see.