Rust Security Team Fixes Miri Bug That Let GitHub Actions Caches Leak Secrets to Pull Requests
The Rust Security Response Team disclosed and patched a Miri flaw that stored all environment variables in target/, letting cached CI output expose secrets to pull requests.
Overview
The Rust Security Response Team disclosed on September 21, 2026, that Miri, the interpreter Rust developers use to catch undefined behavior, “stores all environment variables to target/, allowing secrets to persist in caches,” according to a post on the official Rust Blog written by Manish Goregaokar on behalf of the security-response team. The team said that “while not necessary a vulnerability in and of itself, when paired with GitHub Actions caching behavior, it is possible for this to expose secrets to PRs.”
What We Know
According to the Rust Blog, the underlying mechanism of GitHub Actions caching is normally designed to be safe: “GitHub Actions makes it possible to cache directories between runs. Typical setups allow CI runs on main (and other branches) to write to cache, and PRs can only read from cache (preventing cache poisoning).” Rust projects commonly cache the contents of the target/ build directory to speed up continuous integration runs, the post says.
The problem, per the Rust Blog, is that “when cargo miri is invoked, Miri needs to retain build-relevant environment variables between runs.” The post explains that “the current code to do so achieves this by storing all environment variables to target/,” which “persists when target/ is cached.” As a result, “if your environment contained secrets, these can now be accessed by PRs via the cache.”
The attack path described in the post does not require special access: “PR CI can be triggered by anyone who can open PRs on your repository. GitHub requires maintainer approval for the first PR, but future PRs will rerun CI on every push. Anyone who has previously landed a change can trigger a CI run extracting information from cached target/ and then cover their tracks by pushing a second commit to the PR.” The team also noted that detection is difficult because “GitHub sometimes hides overwritten commits in its UI, making this kind of attack harder to detect,” and that “CI run logs and overwritten commits are also deleted after a few months.”
The Rust Security Response Team said it ran an ecosystem-wide check: “We also performed an ecosystem scan of GitHub repositories and identified 1 repository with this issue and 7 repositories that do not appear to be vulnerable but should be cautious anyway. We have reached out to those maintainers.” The scan, the post says, “was performed using Codex access and credits donated by OpenAI.” The issue itself was reported by “Predrag Gruevski of OpenAI,” according to the acknowledgements section of the post.
The fix, merged the same day as a pull request on the rust-lang/miri GitHub repository titled “only preserve env vars cargo actually changes,” was opened and merged within about an hour — opened at 05:56 UTC and merged at 07:00 UTC on September 21, 2026, per the pull request’s GitHub metadata. The Rust Blog describes the change as making Miri “only preserve CARGO_* environment variables (excepting CARGO_*_TOKEN) and OUT_DIR,” adding that “in the longer term, Miri and cargo may figure out better ways to inform Miri of the relevant list of environment variables.” The Rust Blog states “the Miri release in the upcoming nightly (2026-09-22) will no longer have this problem.”
The post lists who is affected: developers are vulnerable if they “run cargo miri in CI,” the CI step running Miri “has access to secrets as an environment variable,” the workflow “caches the target directory, usually done via actions/cache or swatinem/rust-cache,” and “the cache is accessible to PRs (common and often the intended use case).” Recommended quick fixes include “disabling cache for that job,” “scoping secrets to steps in that job that do not call Miri,” or “temporarily disabling Miri,” and the team advised that once a fix is applied, users should “please clear the cache” and “consider rotating any secrets that might have leaked.”
Beyond the specific Miri bug, the Rust Security Response Team framed the underlying risk more broadly, writing “we consider it bad practice to have a cache that can easily be tainted by secrets,” and cautioning that “Cargo/Miri/Rust does not guarantee that environment variables will be safe from being copied into target/.” The team added that “this is not something you should rely on in general.”
What We Don’t Know
The Rust Blog post does not name the specific repository found to be actively vulnerable in its ecosystem scan, nor does it specify what kind of secrets, if any, were confirmed to have leaked in practice. The post also does not give a precise count of how many total repositories were scanned, only that the scan surfaced one vulnerable repository and seven borderline ones out of an unspecified larger set.
Analysis
The episode is a reminder that CI caching, a feature built to speed up builds, can become a side channel when a tool persists more state than it needs to. The Rust team’s own framing — that this is “not something you should rely on in general” beyond official tooling, since “it is possible for build scripts to be doing things that lead to the environment being stored in compilation artifacts” — points to a pattern that likely extends past Miri to other tools that write build state to cached directories.