Miri Turns a Familiar `target/` Cache Into a Secret-Exposure Risk

The Rust Security Response Team has disclosed a GitHub Actions secret-exposure risk involving Miri, Cargo’s interpreter for Rust’s Mid-level Intermediate Representation. The problem is not Miri alone: it emerges when three conditions overlap—CI runs cargo miri, secrets are present in the Miri process environment, and the workflow caches target/ in a way that pull-request jobs can read.

Miri needs build-related environment data across parts of its execution. The affected behavior stored all environment variables under target/, so caching that directory could preserve credentials, tokens, or other secrets alongside build artifacts. A later pull-request workflow with access to the cache could then inspect the persisted data.

GitHub’s own cache documentation warns that sensitive information should not be placed in cache paths because anyone able to open a pull request may be able to read caches in the base-branch scope. GitHub also documents that pull-request workflows can restore caches from the base branch, which is the access boundary that makes this Rust-specific behavior consequential.

The short-term Rust fix narrows Miri’s preserved environment to CARGO_* variables, excluding CARGO_*_TOKEN, plus OUT_DIR. The advisory says a longer-term solution may give Miri and Cargo a more precise way to identify build-relevant variables. It also cautions that the patch may not be present in nightly immediately; teams should verify the toolchain they actually run.

For affected repositories, the response team recommends disabling the cache for the Miri job, ensuring secrets are unavailable to steps that invoke Miri, or temporarily disabling Miri. After mitigation, clear existing caches and consider rotating credentials that may have been exposed. More broadly, jobs that write public or pull-request-readable caches should not receive secrets, even when they use tools other than Miri: build scripts and compilation tooling can copy environment data into artifacts in ways that are difficult to predict.

The Rust team reports that its scan found one repository with the issue and seven others that did not appear vulnerable but warranted caution. That scan was not exhaustive, so maintainers should inspect their own workflows for the full combination of Miri, secret-bearing environments, cached target/, and pull-request cache access.