فا
← BACK TO THE WIRE
N°0394Rust2 MIN2 SOURCES

Miri Turns a Cached `target/` Directory Into a Secret Boundary

A Rust Security Response disclosure shows how `cargo miri`, broadly scoped secrets, and a PR-readable `target/` cache can combine into credential exposure. ICP Rust teams should audit CI boundaries, clear affected caches, and rotate potentially exposed secrets.

SHARE
Rust
Miri Turns a Cached `target/` Directory Into a Secret Boundary
IMAGE: AI-GENERATED

A new Rust security disclosure puts an ordinary CI optimization under a sharper lens: a cached target/ directory can become a secret-bearing artifact.

The Rust Security Response Team reported on September 21 that Miri stored all environment variables in target/ so build-relevant values could survive across runs. That behavior becomes dangerous when a workflow also exposes secrets to the Miri step, caches target/, and lets pull-request jobs read the cache. In that configuration, a pull request can recover data written during an earlier trusted run.

This is especially relevant to ICP repositories that use Rust canister tooling, nightly components, or extensive GitHub Actions caching. The issue is not that Miri’s interpreter is inherently an exfiltration tool. The failure is a boundary mismatch: a process that can see credentials writes into a directory later treated as shareable build state.

The Rust team’s short-term fix limits Miri’s preserved environment to CARGO_* variables, excluding CARGO_*_TOKEN, plus OUT_DIR. The team said the fix was expected in the nightly release dated September 22, 2026. It also recommends disabling the cache for the job, scoping secrets away from Miri, or temporarily disabling Miri. After containment, maintainers should clear the cache and rotate credentials that may have been exposed.

GitHub’s documentation explains that Actions secrets are injected into workflow execution and automatically redacts only certain sensitive values in logs. That protection does not make files written by tools safe: a secret copied into target/ is an artifact problem, not merely a log-redaction problem.

For an ICP Rust workflow, the practical audit is narrow. Find every cargo miri invocation, identify whether its job receives repository, organization, environment, cloud, registry, or deployment credentials, and check whether target/ is cached or restored for pull requests. Keep credential-bearing jobs separate from jobs that write reusable caches. If a cache was accessible under the risky combination, delete it before assuming the workflow is clean.

One caveat matters: the Rust team says its ecosystem scan may be imperfect, so the absence of a reported match is not proof of safety. Another is that the published change is a short-term Miri fix; the longer-term way for Miri and Cargo to determine the required environment remains unresolved. The broader engineering rule therefore survives the patch: do not give secrets to a job that writes artifacts intended for untrusted or semi-trusted reuse.

TAGSRustMiriGitHub ActionsCI security
Grounded sources2 REFS
  1. [01]GitHub Actions leaking secrets when Miri output is cachedblog.rust-lang.org ↗
  2. [02]Secrets referencedocs.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