فا
← BACK TO THE WIRE
N°0402Rust1 MIN2 SOURCES

Miri’s Cache Lesson: Rust CI Must Treat `target/` as Tainted Output

A Rust Security Response Team warning shows how Miri’s environment handling can turn an ordinary `target/` cache into a secret-exposure path. Rust and ICP developers should audit cache boundaries, secret scope, and existing artifacts.

SHARE
Rust
Miri’s Cache Lesson: Rust CI Must Treat `target/` as Tainted Output
IMAGE: AI-GENERATED

The latest Rust security warning is about a build directory, not a compiler exploit. The Rust Security Response Team reported on September 21 that Miri stored all environment variables in target/ so they could persist between runs. If a CI workflow cached that directory while secrets were present in the job environment, those secrets could persist in the cache and become readable by pull-request builds.

The risk requires a specific combination: the workflow runs cargo miri; the Miri step can access secrets through environment variables; the workflow caches target/, commonly with actions/cache or swatinem/rust-cache; and pull requests can read the cache. GitHub documents that secrets can be passed to a step as inputs or environment variables, which makes broad job-level env settings especially important to review.

This is a useful distinction for ICP canister teams. Miri can help test unsafe code and low-level libraries, but its presence in CI does not make the job a safe place for deployment credentials, registry tokens, signing material, or chain-fusion keys. A cache is an artifact store, not a confidentiality boundary.

The immediate response is operational. Remove secrets from the Miri job, disable caching for that job, or temporarily stop running Miri there. Then clear existing caches and rotate any credentials that may have been exposed. The Rust team says the nightly release dated September 22 contains a Miri change that preserves only CARGO_* variables, excluding CARGO_*_TOKEN, plus OUT_DIR.

There is an important caveat: the Rust team says the ecosystem scan was imperfect, and the behavior is not necessarily a vulnerability by itself. The exposure depends on the workflow’s secret scope, cache path, and pull-request permissions. The broader lesson still applies beyond Miri: any process that writes build output can copy environment data into artifacts, so jobs that write shared or public caches should receive no secrets unless that flow is explicitly designed and reviewed.

TAGSRustMiriCI securityGitHub Actions
Grounded sources2 REFS
  1. [01]GitHub Actions leaking secrets when Miri output is cachedblog.rust-lang.org ↗
  2. [02]Using secrets in GitHub Actionsdocs.github.com ↗
Read next

Get the wire in your inbox

Every new signal, straight from the generator. No noise, unsubscribe anytime.

RSS AVAILABLE · NO SPAM