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

Miri’s Cache Boundary Is Now a Rust CI Security Check

A Rust Security Response disclosure shows how cargo miri, broadly scoped secrets, and pull-request-readable target caches could expose CI credentials—and what maintainers should change now.

SHARE
Rust
Miri’s Cache Boundary Is Now a Rust CI Security Check
IMAGE: AI-GENERATED

The latest Rust security lesson is not about unsafe pointer arithmetic. It is about what a CI job leaves behind.

On September 21, 2026, the Rust Security Response Team disclosed that Miri stored all environment variables in target/ so it could preserve build-relevant state between runs. If a GitHub Actions workflow cached target/, secrets present in the Miri step could persist in that cache and become readable to pull requests.

The issue is conditional, not universal. A project is exposed when four elements overlap: it runs cargo miri in CI; the Miri step can access secrets; the workflow caches target/; and pull-request jobs can read that cache. The Rust team explicitly notes that its ecosystem scan may be imperfect, so maintainers should inspect their own workflows rather than rely on the scan.

For ICP developers, this reframes Miri from a local undefined-behavior checker into a CI isolation boundary. A canister repository may run tests, linting, Miri, and deployment preparation in the same workflow, but those steps do not need the same credentials. Registry tokens, cloud credentials, deployment keys, and other secrets should not be available to a job that writes reusable build output unless that access is essential.

The immediate response is operational. Remove secrets from the environment of Miri jobs, disable target caching for those jobs, or temporarily disable Miri while the workflow is reviewed. If the job may already have exposed credentials, clear the relevant cache and rotate the affected secrets. GitHub’s own guidance also recommends least-privilege credentials, auditing how workflow commands handle sensitive values, and rotating secrets after exposure.

Rust’s short-term fix narrows what Miri preserves: CARGO_* variables except CARGO_*_TOKEN, plus OUT_DIR. The Rust team said the fix would be available in the nightly release dated September 22, 2026. That reduces this specific Miri behavior, but it does not make arbitrary build output safe to cache. The disclosure warns that build scripts and other tools can also copy environment data into artifacts.

The durable rule is simple: treat every cache written by a privileged job as potentially tainted by that job’s environment. For ICP projects, separate verification from deployment credentials, keep pull-request-readable caches away from secret-bearing jobs, and review the workflow whenever a new tool is introduced. Rust found the narrow bug; maintainers still own the boundary around the pipeline.

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